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President’s Corner 
by Bob Niclsen, W6SWE 


Greetings again from Tucson. The Dayton HamVention was great this year. | 
want to thank all of you who dropped by the TAPR booth, even if it was just to say 
“hello.” Sales exceeded all previous years and we sold out of several items. We 
had a Yaesu G5400 az-el rotator (courtesy of Yaesu USA) set up to demonstrate the 
TrakBox. Pete Eaton, WB9FLW and his dad, Jim, built a miniature antenna mode! 
out of PVC pipe and piano wire and it made a very effective demonstration of the 
tracking capabilities. (Several people asked if they could buy the antennas! Sorry, 
they were completely non-functional.) It was nice to meet many of the members 
and friends of TAPR and I apologize if I missed any of you. It got quite hectic at 
times. The packet forum was well-attended, as well. 


Speaking of the TrakBox, at the time I am writing this (late July), TAPR has sold 
over 100 of the kits. We have nearly 100 boards left and are kitting them up. When 
these are gone, there will be no more. JAMSAT has announced that they will not 
be making any more of the boards, but will be licensing the design for production 
by commercial manufacturers. 


1 feel the need to comment on some recent happenings. As many of us are well 
aware, the special temporary authority (STA) under which the automated HF BBS 
forwarding takes place will not be renewed next year, and unless some rule changes 
are forthcoming, such forwarding within the U.S. will no longer be legal. The 
ARRL Committee on Amateur Radio Digital Communications released on June 13 
its report on unattended HF digital operations. I only learned of the report and 
obtained a copy a few days prior to the Board meeting and was unable to input any 
comments to my division Director. This report, which was adopted by the ARRL 
Board of Directors at its meeting on July 17, is based, in part, on the responses to a 
survey which was in the January, 1992 issue of QST. One comment I have seen, 
which would appear to be quite valid, is that the results of the operation under the 
STA were not evident in the report. 


The committec has recommended that only semi-automatic unattended operation 
be permitted on frequencies below 30 MHz. What this means is that only a station 
with a contro! operator present may initiate a contact with an unattended station. 
Much of what I have seen in response to the committee’s recommendations has been 
inflammatory, claiming that it would be the end of HF digital message forwarding. 
Whether that would be the case or not remains to be seen. It would, however, have 
a serious impact on such operations. I am not a participant in the HF forwarding 
net, but from what I have seen, including many messages sent and received which 
have passed through this network, the “system,” as currently operated under the 
STA, works. There are certainly many issucs here, and if the ARRL proposes the 
committee’s recommendations in their current form to the FCC, there will hopefully 
be adequate opportunity to comment. Hopefully, currently available (and future) 
technology will not be overly restrained by regulation in this case, but history does 
not lead one to be very optimistic. 


On a more positive note, the FCC 
has proposed, based mainly on a 
proposal from the ARRL, that certain 
changes be made in Section 97.113 of 
the Amateur rules relating to 
prohibited transmissions. This would 
replace the prohibition against trans- 
mitting “any communication the pur- 
pose of which is to facilitate the busi- 
ness or commercial affairs of any 
party” with a prohibition of com- 
munication for hire (except as spelled 
out) or in which the station licensee or 
control operator have a pecuniary in- 
terest. I believe that such a change 
would be beneficial and would avoid 
the kind of situation encountered in the 
“900 number” incident last year. How- 
ever, I also believe that we, as 
Amateurs, should impose a certain de- 
gree of self-restraint in the types of 
communications we originate. The 
packet BBS system is virtually overrun 
with bulletins that are of dubious inter- 
est to most of us. Is someone 
thousands of miles away really going 
to be interested in buying your 500 
pound tower? Is it necessary to follow 
the sale of a piece of equipment with a 
bulletin telling the whole world that it 
is no longer available? Of course not. 
Opening up the permitted areas of 
communication will probably provide 
additional opportunities for those who 
wish, for whatever reason, to abuse 
their privileges. My premise here is 
that it is far better if we employ self- 
imposed limits than to have them im- 
posed by statute or regulation. We 
hopefully will be gaining something 
with this proposed regulation change. 
Let’s use it responsibly. 


TAPR 9600 bps Modem 
Notes 


by Lyle Johnson, WA7GXD 


Anumber of folks have written with 
Suggestions, modifications, and ques- 
tions about the new TAPR 9600 bps 
modem kit. In this article I will 
describe these and include actions or 


options for you to consider. 


Q: The CON LED on my TNC-2 
remains off. The CON status never 
appears at the output of the RS232 
connector on the back of the TNC- 
2. 


A: This problem is due to a logic error 
in U13. TAPR now hasa corrected 
PLD for U13 labelled U13A. If 
your kit’s U13 is not labelled 
"U13A" or "U13R1", you may send 
your old PLD along with an SASE 
to TAPR and we will reprogram it 
for you for free until 31 October 
1992. Be sure to pack the PLD ina 
safe manner, including anti-static 
foam. 


NOTE: You must specify whether or 


not you want U13A or U13R1. If 
you don’t specify, we will send 
UI13A. U13R1 is only necessary if 
you perform the modifications 
detailed later in this article. 


The quick "fix" is tocut the trace on 
the bottom of the modem PC board 
between U13 pin 14 and P2 pin 7. 


Q: What sort of waveforms should I 
see on my 9600 bps modem? 


A: A new schematic set has been made 
and annotated with waveforms and 
voltages. This is a five-page 
schematic for greater readability. 
In addition, an updated schematic 
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Packet Status Register 


with all mods. to the modem (see 
below) is also available. 


These schematics are in all the new 
kits. If you have an older kit, you 
may obtain a set by sending an 8- 
1/2" by 11” self-addressed, 
stamped, envelope with postage for 
two ounces. 


: How do I use the BER test point? 
: To use this feature, you must have 


asecond station which can send you 
data at 9600 bps. The other station 
should set his TNC to CAL mode, 
either “mark” or "space" (some 
TNCs do not support this mode -- 
all TAPR TNCs do. If yours does 
not, simply lift lead of U9 pin 12 out 
of its socket and jumper this pin to 
the GND test point). 


NOTE: Since this cal "tone" will be 


sent through the transmit 
scrambler, you will not see a 
steady-value waveform over the 
air. 

The distant station should then 
transmit. 


At the receiving end, hook an oscil- 
loscope or speaker amplifier to the 
BER test point. When recciving a 
strong signal this should be a steady 
high or low value (the speaker will 
be quiet). 


Now, reduce the signal level until a 
popping noise is heard (or “spikes” 
appear on the oscilloscope display). 
Adjust R15 for the slowest noise 
pulse rate with a weak signal. 
Verify that the popping goes away 
with a somewhat stronger signal. 


NOTE: If you decide to get fancy 


and use a frequency counter (not 
at all necessary), remember that 
you will get a burst of three pulses 
for every bit that is in error... 


If your radio can be aligned in its IF 
(only old radios) then do so for 
lowest signal level before popping 
occurs. 


NOTE: Be sure to replace U9 pin 12 


to its socket after testing. 


Q: I have a TNC not listed in the 


specific instructions section of the 
9600 bps modem manual. I find the 
"Generic Installations” information 
a bit intimidating. Help! 
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A: TAPR now has available detailed, 
tested installation information for 
the AEA PK88, AEA PK232MBX, 
DRSI PC*PA and TAPR TNC 1 
(and clones). I would like to thank 
AEA and DRSI for their assistance 
in providing this information, as 
well as those TAPR volunteers who 
lent equipment or suggestions 
during these tests. 


Q: The 9600 Baud Packet Handbook 
by Mike Curtis, WD6EHR, that is 
included with the modem kit shows 
coupling circuitry anda TXA cutoff 
relay. It is pretty hard to fit this into 
aradio. Could TAPR make a small 
PC board for all this stuff to make 
the interfacing task a bit easier? 


A: If you think this is a good idea, write 
to the TAPR office and let us know! 
If there is enough interest, such a 
board could be made. 


Q: Brian, KC6HPN, has pubished a list 
of mods to the TAPR 9600 bps 
modem. I have heard that these 
mods may improve performance. 
Should I perform them? If so, is 
there an easier way to implement 
them? 


A: Ihave gathered reports from various 
packeteers about this set of mods, 
and checked into them myself as 
well. I recommend the following 
mods: 


A) Remove C5 in existing units. This 
will stop any tendency for transmit 
audio op-amp oscillation. 


B) Change U4 from a TLO84 to a 
TLC274. This change will 
dramatically improve the threshold 
margin for sliced data. 


C) Change U19 from a 74HC04 to a 
74HC14, This will result in better 
response for the slow edge from 
U1] via R34 and C24. NOTE: 


NOTE: I don’t recommend remov- 
ing R34 and C24 as these deal 
with suppressing a 100 to 150 
nSec wide "glitch" that occurs on 
the output of U1ID (pin 11) due 
to propagation delays in 
U7A/U8/ULIC to U11D (pin 12) 
versus the delays in the path to 
UID (pin 13). 


Most folks report that the greatest 
gains come from the removal of C5 
and changing U4 to a TLC274. 
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The gains from clock synchroniza- 
tion are a litle harder to quantify. 
However, if you want to do them, 
the following procedure will do it 
without glueing another chip to the 
PC board. 


D) On the top of the modem PC board 
cut the following trace: 
C1) Ul6pin2t R19 


On the bottom of the modem PC 
board cut the following traces: 

OC U13 pin 14 to P2 pin7 

1) U13 pin 15 to RP2 pin8 

(1) U13 pin 11 to U14 pin 10 

C) U13 pin 1 to RP2 pin 2 

1 U7pin i2toR19 


On the bottom of the modem PC 
board add the following wire 
jumpers: 

U13 pin 1  U13 pin 13 

U13 pin 11 to RP2 pin 2 

U13 pin 15 to U16 pin 2 

U16 pin 2 to U7 pin 12 

U13 pin 19 to D2 anode 


Replace U13 with one labelled 
“U13R1". 

If you choose to do these mods, 
TAPR wil provide a kit of parts con- 
sisting of a 74HC14, a TLC274 anda 
programmed "U13R1" for $5. If you 
have a new kit, the only part needed 
will be U13, and we will be happy to 
re-program yours for you. Simply send 
your old U13 PLD along with an SASE 
to TAPR and we will reprogram it for 
you for free until 31 October 1992. Be 
sure to pack the PLD in a safe manner, 
including anti-static foam. 


DOOOOd 


Renew Your Membership! 
TAPR doesn’t send out constant 
reminders when your membership 
has expired. Our only way of com- 
municating your expiration date to 


you, is the date on the address label 
for this issue. Please check it and 
renew if required. Your member- 
ship is very important. 
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Interfacing the TAPR 
9600 bps Modem to an 
AEA PK88 


by Lyle Johnson, WA7GXD 


The TAPR office recently acquired 
an AEA PK-88 TNC. I interfaced a 
TAPR 9600 bps modem to it. Here’s 
how it was done: 


Mechanical 

The modem will not easily fit inside 
the PK88. The heatsink for the PK88 
voltage regulator is in the way and has 
to be trimmed. Crystal XTAL1 and 
capacitors C19, C36 and C39 must be 
laid down. Jumpers JP3 and JP7 may 
have to be trimmed. Since I was using 
a borrowed unit at the time, I decided 
10 not try these mods! 


As a result, the modem should be 
mounted in its own shielded metal 
cabinet with all leads properly 
bypassed for the RF environment it is 
expected to operate in. Shielded cable 
should be used to connect the modem 
to the TNC, and this cable should be as 
short as practical for reasons of electri- 
cal interference. 


Electrical 

The PK88 external modem inter- 
face has the same problem as the 
PK232 external modem connector — 
insufficient signals are brought to the 
connector. The signals that are avail- 
able are provided in a way that 
precludes easily using a switch to 
select between internal and external 
modems. 


However, the PK88 design docs 
lends itself well to a simple modifica- 
tion to enable the use and selection of 
an external modem. Read on! 


The Nitty Gritty 

The PK88 brings its external 
modem connections to otherwise un- 
used pins of the RS-232C 25-pin serial 
port connector. There are a number of 
unused pins on this connector. After 
you make these modifications, you 
will need to use a specially wired RS- 
232C serial port connector with your 
PK88. But, you will be able to easily 
use your PK88 with external modems 
such as the TAPR 9600 bps and the 
TAPR 1200 bps PSK modems. 
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The RS-232C connector J1 comes 

wired from AEA as follows: 

Pin Function 

1 Frame Ground (PK88 chassis) 

2 RS232 TXD (data in to PK88) 

3 RS232 RXD (data out from PK88) 

4 RS232 RTS (signal in to PK88) 

5 RS232 CTS (signal out from 

PK88) 

RS232 DSR (output, pulled to +10 

inside PK88) 

7 Signal Ground (PK88 signal) 

8 RS232 DCD (output from PK88) 

9 nic 

10 may be jumpered to pin 6 via PK88 
internal jumper JP9 

11 n/c 

12 n/c 

13. TTL CLK - output from PK88 at 
32x radio channel data rate 

14* TTL DCD - input to PK88 from 
external modem 

15* TTL RXD - input to PK88 from 
external modem 


ion 


16* TTL TXD - output from PK88 to 
external modem 

17 Ground, same as pin 7 

18 n/c 

19 nj/c 

20 nfc 

21 n/c 

22 n/c 

23 frame ground 

24 n/c 

25 nf/c 


NOTE: The signals marked with an 
asterisk (*) are only enabled 
when the appropriate internal 
jumper is placed in the PK88, 
which simultaneously disables 
the internal modem. 


Connector J1 will be modified to 
use the following pins: 
12 Ground 
13. TTL 32x clk from PK88 
14* TTL DCD to PK88 
15* TTL RXD to PK8&8 
16* TTL TXD from PK88 
18 TTLRTS from PK88 
19 TTLRTS to PK88 intemal modem 
21 TTLRXD from internal modem 
22 TTL DCD from internal modem 
24 Switched +12v from PK&88 


After performing these modifica- 
tions, the PK88 will require the follow- 
ing pins to be jumpered in the RS-232C 
serial port cable connector to enable 
the internal modem for normal use: 
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() Pin 14 to pin 22 (enables radio 
channel DCD) 

(] Pin 15 to pin 21 (enables radio 
channel RXD) 

(J Pin 18 to pin 19 (enables radio 
channel PTT) 

Finally, be absolutely certain that 
your RS-232C cable doesn’t connect 
pins 13-16, 18, 19, 21, 22 or 25 (these 
are almost never used, and certainly 
not by PCs such as Amateurs use!). 


Performing the Modifications 

1. Remove power from the PK88. 
(This means to physically discon- 
nect the power supply from the jack 
on the PK88, not merely turning it 
off!) 


2. Remove the PK&8 from its cabinet, 
and remove the PC board from the 
cabinet base. 


3. Place all three JP4 jumpers toward 
rear edge of PC board and center 
pins. 


WAS: 


"top” row 


Boom A 
Boom A 
BO oO A “bottom” row 


Rear of PK88 


Bomoo ¢ “top” row 
Bom o é. 
BOO oO A “bottom” row 


4. On the bottom of the PK88 PC board 
add the following wire jumpers: 

() JP4 center row pin "A" to J1 pin 

21(rxd from internal modem) 

JP4 top row pin "A" to J1 pin 22 

(ded from internal modem) 

Ji pin 7 to JI pin 12 

(gnd) 

Junction of R10/R11 toJ1 pin 19 

(rts to internal modem) 

IC12 pin 17 to J1 pin 18 

(rts from PK88) 

Plus side of C2 to J] pin 24 

(switched +12v from PK88) 


i 4 th 2 


5. On the bottom of the PK88 PC 
board, cut the trace leading away 
from the junction of R10/R11. 
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6. Reassemble the PK88. 


7. Wire an RS-232C cable to your 
computer and make sure the PK88 
end of the cable is wired as follows: 
Pins 1-8, 10, 17 and 23 as before. 
Pin 18 jumpered to pin 19. 

Pin 15 jumpered to pin 21. 
Pin 14 jumpered to pin 22. 

8. Apply power to the PK88 and verify 
that it works normally before 
proceeding. Include an on-the-air 
test to verify the internal modem is 
functioning properly. 


9. Construct the TAPR 9600 bps 
Modem kit. Include the internal 
LEDs and the voltage regulator, but 
do not install the internal clock or 
bit regenerator options. 


10. Ensure that no jumpers are placed 
on the 9600 bps modem. 


11. Wire an RS-232C cable to your 
computer and make sure the PK88 
end of the cable is wired as follows: 


PK88 9600 bps modem 
pins 1-8, 10, 17, and 23 as before. 
12 Ground 15 
13 32x Clk > 11 
14 DCD < 1 

15 RXD — 17 
16 TXD > 19 
18 RTS > 5 

19 RTS <— 6 

21 RXD > 18 
22 DCD > 2 

24 +12v 26 


12. Set the PK88 to FULLDUP ON 
and HBAUD 9600. 


13. Place a jumper at modem P1 pins 
1 and 2. 


14. The DCD LED should illuminate. 
If it does not, troubleshoot the 
modem and cabling. 


15. Connect to yourself. 


16. Note that the PTT LED on the 
modem flashes when you connect. 


17. Disconnect. 
18. Set FULLDUP OFF. 


Remember to short JP4 on the 
modem to enable the PK88 internal 
modem. You must also reset HRAUD 
1200 (or 300) to use the internal 
modem. 


Enjoy 9600 bps operation with your 
PK88! 
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Interfacing the TAPR 
9600 bps Modem to an 
AEA PK232MBX 


by Lyle Johnson, WA7GXD 


The following information is a 
result of the loan of a PK232MBX with 
the "new" motherboard from Bobby 
Miller, K8KIK, and detailed informa- 
tion provided by Robert Donnell, 
KD7NM, of AEA Customer Service. 


PK232MBxX internal Installation 

The following directions apply to 
PK232s above serial number 45933 
with the PakMail function installed on 
the motherboard. If your unit has a 
daughterboard card plugged into sock- 
ets on the motherboard labeled U2 and 
U4, refer to the "PK 232 Internal Instal- 
lation" directions. 


This section assumes you have the 
TAPR PK232 Modem Disconnect 
Header modification kit. If you do not, 
one may be obtained from TAPR. If 
you prefer to not use the modem dis- 
connect, refer to the "Generic Installa- 
tions” section of the manual. 


In addition to the TAPR Modem 
Disconnect kit, you may wish to use 
the TAPR PK232MBX Installation kit, 
which contains prewired plug ’n’ play 
harnesses and all hardware needed for 
installing the 9600 bps modem inside 
your PK232MBX. Thiskitis available 
from TAPR., 


Modem Preparation 

Perform the following steps tocom- 
plete assembly of your modem 
prepared for internal PK232MBX in- 
stallation. 


US: 

(7 Install the LM7805 voltage 
regulator at US on the modem 
board. The regulator should lay 
flat against the surface of the 
board. There is no need to fasten 
the regulator with screws as the 
modem draws very little current 
and the regulator will not over- 
heat. 

Pl: 


NOTE: The 5-pin right-angle male 
header will be installed on the 
BOTTOM side of the modem PC 
board. 
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C) Place the 5-pin right angle con- 
nector on the bottom (solder) 
side of the modem PC board. It 
should rest on the bottom surface 
of the board. The pins from the 
connector should “point” 
towards the PC board, not away 
from it. See illustration below. 


i TOP , 


PI 


[L) Check the clipped leads from 
R1-R6 and C1-C9 and verify 
that they are flush, or nearly 
flush, with the PC board. Clip 
and reheat the connections as 
necessary. This will ensure 
proper fit of the mating connec- 
tor, attached later. 

(C$ Solder the 5 pins of the connec- 
tor to the top of the PC board. 


Study the illustration below before 
mounting P2. 


(1 Cutthe trace on the top of the PC 
board which joins P2 pins 9 and 
10. 

() Cut the supplied 26-pin male 
header to a 20-pin header. 


() Solder the header to the PC 
board so it occupies pins 1 
through 20 of P2. The short pins 
go into the PC board; the long 
pins stick up from the top of the 
PC board. 


CJ Cut a 2-pin header from the 
remaining 6-pin portion of the 
header used for P2. 

(0 Solder this connector to pins 24 
and 26 of location P2. 

Jumpers: 

(0 Be sure you have NO shunts in- 

stalled at JP2, JP3 or JP4. 
Options: 
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(1) The CLOCK option, if installed, 
must be disabled by leaving JP3 
open. 

(1 The BIT REGENERATOR op- 
tion, if installed, must be 
removed, This is done by simply 
removing ICs U1, U2 and U3 
from their sockets. 


PK232 Preparation: 

(1 Remove the upper case from the 
PK232 by removing the six (6) 
screws that fasten it to the main 
chassis. 

C1 If you have not already done so, 
fabricate, install and check out 
the TAPR PK232 Modem Dis- 
connect kit. 


() Remove the two screws on the 
PK232MBX motherboard in the 
center (one at the rear edge be- 
tween J7 and J8, the other near 
U38 and Q10 towards the front 
pane! of the unit). 


( Remove the jumper at JP-8. 


NOTE: Skip to Modem Integration 
Using TAPR PK232MBxX Instal- 
lation Kit if you are using the 
TAPR PK232MBX Installation 
kit. 

Cabling - Not using the TAPR 

PK232MBxX Installation Kit 

() Fabricate an 8" (20 cm) long 
cable with a 20-pin female IDC 
header ateach end, such that pins 
1 are tied together, pins 2 are tied 
together, etc., through pins 20. 
(see illustration) 


(C Fabricate a 8" (20 cm) long 
single-wire cable with a two-pin 
header shell at one end and a 
stripped, tinned wire at the other 
end. 

[) Fabricate a 3.5" (9 cm) long 
cable with a push-on shuntatone 
end and a stripped, tinned wire at 
the other end. 

() Fabricate a 5-wire cable 4" (10 
cm) long using a 5-pin connector 
shell using ribbon cable as fol- 
lows. The other end of each wire 
should be stripped and tinned. 
Pin! Brown 
Pin2 Red 
Pin3 Orange 
Pin4 Yellow 
Pin5 Green 
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PIN 20 


PIN 2 


0 


PIN 1 


PIN 1 


bg——_________. 8 inches. —————_>! 


ss 


Modem Integration 
(1 Ensure that JP4, JPS and JP6 on 


the Pk232MBX motherboard 
are installed at the "B” positions 
for each of these jumpers. 
Attach the 5-pin cable to P1, on 
the underside of the modem. 
Using 3/4" #6 spacers and 7/8" 
6-32 screws, install the modem 
on the PK232 motherboard, 
spacing above the motherboard 
and using the two screw holes 
vacated above. 

Solder the free end of the 3.5" 
wire to J13 pin 5. 


Place the shunt on the free end of 
the wire soldered to J13 pin 5 to 
pins 24 and 26 of P2 on the 
modem. 

Solder the free end of the 8" wire 
with the two-pin shell shunt at- 
tached to J13 pin 2. 


Place two-pin shell end of the 8" 
wire just soldered to J13 pin 2 to 
JP4 on the modem. The single 
wire in this connector shell con- 
nects to the pin of JP4 nearer the 
label "U22". 


Solder the five (5) wires from the 
five-wire cable fabricated above 
to the PK232MBX motherboard 
as follows: 

Brown JP4end "A" 

Red JPSend"A” 

Orange J13 pind 

Yellow J13 pin9 

Green JP8 center pin 


Proceed to Further Steps - All 
PK232MBxX Installations, below. 


Modem Integration Using TAPR 
PK232MBxX Installation Kit 
(1) Remove any shunts on jumpers 


JP4, JPS and JP6 on the 
Pk232MBX motherboard. 
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0 


Attach the 5-pin connector 
labelled "P1" from the wiring 
harness to Pl, on the underside 
of the modem. 

Using 3/4” #6 spacers and 7/8" 
6-32 screws, install the modem 
on the PK232 motherboard, 
spacing above the motherboard 
and using the two screw holes 
vacated above. 

Plug the shell marked "#1" from 
the wiring hamess to J13 on the 
PK232MBX motherboard. 

Plug the shell marked "#2" from 
the wiring harness to JP4, JPS 
and JP6 on the PK232MBX 
motherboard. 

Plug the shell marked "#3" from 
the wiring harness to JP8 on the 
PK232MBX motherboard. 

Plug the shell marked "#4" from 
the wiring harness to P2 pins 24 
and 26 on the 9600 modem. The 
single wire in this connector 
goes to pin 26. 

Plug the shell marked "#5" from 
the wiring hamess to JP4 on the 
9600 modem. The single wire 
connects to the pin on JP4 nearer 
the legend "U22". 


Further Steps - All PK232MBX 


0 


Installations 


Form the 20-pin cable into a "Z" 
shape as shown below. 


O 


Oo 
O 


Insert one end into the modem 
header P2, with pin 1 near the 
silkscreen legend "P2". 

Remove any jumpers from the 
Modem Disconnect header P1. 
Insert the other end of the 20-pin 
cable into the Modem Discon- 
nect header, P1, with pin 1 near 
the silkscreen legend "Pt". 


initial Checkout 

Apply power to the modem and 
verify that +5 volts appears between 
U13 pin 20 and U13 pin 10. 


Remove power from the modem 
and install the following ICs: 


O 
O 
0) 
Oo) 


OOOOO OO DOOOoOOOoOO 


U1 DONOT INSTALL! 
U2 DONOT INSTALL! 
U3 DONOT INSTALL! 
U4 TLO84 

U6 74HC4060 (optional, not 
used) 

U7 74HC74 

U8 CD4006B 

US 74HCT4 

U10 CD4006B 

Ull + 74HC86 

Ul12 74HC4538 

U13 16V8 or 18CV8 
U14 16V8 or 18CV8 


U15 27C64 labelled "STATE 
2.00" 


U16 74HC574 


U17 27C64 labelled "TX9600 
1.0" 


U18 74HC574 
U19 74HCO4 
U20 AD7523 
U21 74HCT393 
U22 TLO84 


Be sure all the ICs are properly 
seated, and that no pins are folded 
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under a chip or hanging over the edge 
of a socket. 
O Apply power to the PK232MBX 
and verify that the PK232MBX 
signs-on as normal. 


NOTE: If the PK232MBX seems 
sluggish, or takes a long time to 
reset, or never resets and signs- 
on, check your power supply volt- 
age to the PK232MBX. The 
modem adds 50 mA or so of cur- 
rent drain, and marginal power 
supply (one rated at 500 mA, for 
example) will cause the system to 
exhibit this symptom. The 
modem is not at fault; replace the 
power supply before proceeding! 


(J Place a jumper across pins ! and 
2 of the PK232MBX “EXT 
MODEM" connector on the rear 
panel of the PK232MBX. 


C1 Preset R15 on the modem board 
to full CCW, then 1/8 turn CW. 
CI Preset R30 to mid-range. 
(1) Issue the following commands 
to the PK232MBX: 
HBAUD 9600 
FULLDUP ON 
These commands will set the 
HDLC data rate to 9600 bps and tell the 
PK232MBX to ignore the DCD LED. 
C] Note that the modem’s DCD 
LED is off. 


C1 Issue the command 

ALTMODEM 1 
and the DCD LED should il- 
luminate on the modem board. This 
tells you that the modem is “hear- 
ing" and decoding its transmit data 
via the loopback connection. 

(C$ Issueaconnectto yourself. This 
will check out the receive 
decode portion of the modem. 
Note that the PTT LED will flash 
on the modem along with the 
“SEND” LED on_ the 
PK232MBxX front panel. 


You may restore normal operation 
to your PK232MBX by issuing the 
ALTMODEM 0 command to select 
the normal modem, and setting 
HBAUD towhatever data rate you nor- 
mally use. Remember to reset 
FULLDUP OFF or your transmitter 
will gleefully step on other stations’ 
signals! 
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At this point, initial checkout is 
complete. You will next have to inter- 
face the unit to your radio, modify the 
radio as necessary, and set the R15 
compensation and R30 output level for 
the correct transmitter deviation. 


Consult the manual from Mike Cur- 
tis, WD6EHR, for general radio inter- 
facing information. 


When you have performed the in- 
terface, proceed to the section in the 
manual entitled FINAL CHECKOUT. 


Interfacing the TAPR 
9600 bps Modem to a 
DRS! PC*PA 


by Lyle Johnson, WA7GXD 


PC*PA interface 

The information presented is 
specific to the Type 1 PC*PA (port 0 
fixed at 1200 bps with internal modem, 
port 1 set up for extemal modem). 
Other styles of the PC*PA may vary, 
so double check your unit before 
proceeding! 


PC*PA Setup 

The external modem port must be 
set up for TTL interface levels. Infor- 
mation to do this is included in the 
Hardware Reference Manual provided 
with the PC*PA. Please read that sec- 
tion of your manual before proceeding 
with the following steps. 


1) If you havea very early PC*PA, you 
will find the RS232 level translator 
chip is U9 (MC145406). IF you 
don't have this configuration, skip 
to step 2. 


NOTE! This information for the ear- 
lier units is based on schematic 
diagram analysis only! 

C1 Remove your PC*PA from your 
computer. 

(J Locate U9 (MC145406) and 
remove it. 

{) Preparea 16-pin header, jumper- 
ing pins 2-15, 3-14, 4-13, 5-12, 
6-11, 7-10. Leave pins 1, 8, 9 
and 16 unconnected. On the cir- 
cuit side of the PC*PA PC board, 
cut the trace going from U9 pin 
7 to U7 pin 28 (the 8530 SCC 
chip). 
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U9 Header 


Top View 

CJ On thecircuit side of the PC*PA 
PC board, solder an insulated 
jumper wire from U9 pin 7 to U7 
pin 26. 

(J Place a jumper at JP2 on the 
PC*PA to power the TAPR 
modem. 


(0 Proceed to TAPR 9600 bps 
Modem Setup below. 


2) If you have a later PC*PA, you will 
find TTL <-- RS232 level conver- 
sion is handled by U13 (MC1488) 
and U14 (MC1489). If this is the 
case: 

(J Remove the PC*PA from your 
computer. 

(1) Locate U13 (MC1488) and 
remove it. 

(] Preparea 14-pin header, jumper- 
ing pins 2-3 and 8-9. Pins 1, 4-7 
and 10-14 should remain uncon- 
nected. 


(1) Install the 14-pin header at U13. 

C Locate U14 (MC1489) and 
remove it. 

(C) Preparea 14-pin header, jumper- 
ing pins 1-3, 8-10 and 11-13. 
Pins 2,4-7, 9, 12 and 14 should 
remain unconnected. 

(1 Install the 14-pin header at U14. 


9 
IQ? 
U14 Header 


Top View 
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(J Place a jumper at JP3 on the 
PC*PA to power the TAPR 
modem. 


TAPR 9600 bps Modem Setup 
All references to page numbers 

refer to the 1! April 1992 edition of the 

TAPR 9600 bps Modem Kit manual. 


Do NOT use the internal clock op- 
tion on the 9600 modem. Do NOT 
install the BitRegen option on the 
modem, 


In the regular construction section 
of the manual: 
C) Install R29 and R33 (page 9). 
C Install the LEDs (page 13). 
Refer to the "Generic Installations" 
section of the TAPR manual (starts on 
page 28). 
(.) P! should be installed on the top 
of the PC board. 


1 P2should be installed as a26-pin 
male header on the top of the PC 
board. You may ignore the 
directions regarding pins 5, 9 
and 10 at the top of page 29. 
They will have no effect on the 
DRSI system whether they are 
performed or not. 

Install US. 

You must prepare acable to con- 
nect between the 25-pin D con- 
nector on the PC*PA and P2 on 
the modem. Use 8-conductor 
shielded cable and wire it as fol- 


oO 


lows: 

Eunction. DB-25P_ — 26-pin 

Shield 1 and shell 

Ground 1 15, 25 

Tx0B 2 19 

RXDB 3 17 

‘RTSB 4 § 

ICTSB § § 

Ground 7 15, 25 

{OCDB 8 1 

+12VDC 11 26 

32XCLK 15 11 (see note, 
below) 


NOTE: Use pin 11 for the 32X clock 
if using a standard PK232/TNC2 
PLD at Ul4. If the PLD at Ul4 
on your 9600 modem is labelled 
“U14-1" it is for a TNCI/TFNC2 
option and use pin 12 of the 26- 
pin header instead. 
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C Install the PC*PA in your com- 
puter and connect the modem to 
it via the cable just prepared. 

[) Apply power to the computer 
and verify that +5 volts appears 
between modem IC socket U13 
pin 20 and U13 pin 10. 


Remove power from the com- 
puter and install the ICs indi- 
cated beginning on the bottom of 
page 29 of the TAPR manual. 
Ensure there is NOT a jumper 
placed at JP2 on the modem. 
Ensure there is NOT a jumper 
placed at JP3 on the modem. 
Ensure there is NOT a jumper 
placed at JP4 on the modem. 
Power up your computer and use 
the CONFIG22 utility supplied 
by DRSI to set Port 1 HBAUD 
to 9600 bps (HBAUD 5) and set 
DUPLEX ON (DUPLEX 1). 
Refer to the DRSI documenta- 
tion for details on this, 

Place a jumper across pins 1 and 
2 of modem connector P1. 
Preset R15 on the modem board 
to full CCW, then 1/8 tum CW. 
Preset R30 to mid-range. 

The modem’s DCD LED should 
illuminate. If it does not, 
troubleshoot the modem and ca- 
bling. 

(1) Connect to yourself on Port 1. 
Note that the PTT LED flashes 
on the modem. 


(J Disconnect. 


O 


O O00 


OO Oda 


Preliminary checkout is done. 


I recommend that you install your 
9600 bps modem in a well-shielded 
cabinet and use a minimum length 
shielded cable between your PC*PA 
and the modem. Install the appropriate 
connectors for your radio, label the 
LEDs, etc. 


Welcome to 9600 bps packet radio 
with your PC*PA! 
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Interfacing the TAPR 
9600 bps Modem to a 
TAPR TNC-1 


by Lyle Johnson, WA7GXD 


TNC-1 Setup 
Perform the following modifica- 
tions to your TNC-1: 

C) Solder a jumper wire across R79 
(680 ohm) located near modem 
disconnect J5. 

If your TNC-1 already has amodem 
disconnect header installed at J5: 

(J Remove any jumpers placed at 
modem disconnect header J5. 

(CJ Remove extractor “ears” from J5 
if present. 

If your TNC-1 has no modem dis- 
connect header installed at J5: 

(CO install the 20-pin male header 
provided with the modem kit at 
J5. 


C) Cut any default traces tying 
modem disconnect header pins 
together. These will usually be 
1-2, 3-4, 5-6, 7-8, 9-10, 11-12, 
13-14, 15-16, 17-18, and 19-20. 

If you intend to mount the modem 
inside the TNC-1 case and plug it 
directly into J5: 

(1 C3. and CS are too tall and must 
be laid down. You may have to 
replace them or extend their 
leads to accomplish this. Lay 
them towards power supply 
diodes D9-D12. 

NOTE: The following step is only 
necessary if you intend to use the 
TNC-1 internal clock and not the 
clock option on the 9600 bps 
modem. 

(J) Place jumper JP7 on the TNC-1 
PC board across the pin pair 
nearer C12 - the default is the 
pair farther from C12. This will 
run the 6809 CPU at twice nor- 
mal speed (1.84 MHz). The 
6809 CPU, 6522 VIA and the 
6551 ACIA chips may need to be 
replaced with higher speed parts 
("B" or -2 parts) for reliable 
operation at the higher speed. 


TAPR 9600 bps Modem Setup 
All page number references are for 
the 1 April 1992 manual. 
(C Install R29 and R33 (page 9). 


(install the LEDs (page 13). 
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Refer to the “Generic Installations" 
section of the TAPR modem manual 
(starts on page 28). 

C) P1 should be installed on the top 
of the PC board. 


() DO NOT PERFORM THE 
TRACE CUT AT P2 PINS 9 
AND 10! 


DO NOT INSTALL THE 
JUMPER AT P2PINS 5 AND9! 
C1 If you are going to directly plug 
the modem into J5 on the TNC- 
1, use a 20-pin female conncctor 
installed on the bottom of the 
modem PC board at P2. 
C) If you are going to use a 20-pin 
ribbon cable to connect your 
modem to case access to the 
LEDs and P1 radio connector, 
use a 20-pin male connector in- 
stalled on the top of the modem 
PC board at P2, 


CJ Install US. 


C) Attach a wire from modem P2 
pin 26 to +12 volts available at 
the TNC-1 wire wrap area. 

Proceed with the "Generic Installa- 
tion” checkout and IC installation pro- 
cedures beginning on page 29 of the 
modem manual. 

C) Replace the standard U14 PLD 
with one marked "U14-1". 
NOTE: The 9600 bps modem chips 
are now set for TNC-1/TNC-2, 
and will not work with the 

PK232. 


O 


Checkout Information 

The following assumes you are 
using TAPR/HEATH/AEA firmware. 
(WA8DED firmware commands are in 
parentheses like this.) 

(1 If you are using the TNC-1 
HBAUD generator with a 
double-speed CPU clock, select 
HBAUD 4800 (<ESC>H9600) 
for 9600 bps operation and 
HBAUD 600 (<ESC>H1200) 
for 1200 bps operation. 
(<ESC>@C1 to enable double 
speed clock for WA8DED 
firmware.) 

(1 If you are using the modem in- 
ternal clock option, place a 
jumper on the modem at JP3. 
HBAUD (<ESC>H) will have 
no effect on the modem opera- 
tion if this is done. 

C) Place ajumper at modem P! pins 
1 and 2. 
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a) 


The DCD LED should il- 


luminate. If it does not, 
troubleshoot the modem and ca- 
bling. 

C Set FULLDUP ON 
(<ESC>@D1). 

[1 Connect to yourself. 

O Note that the PTT LED on the 
modem flashes when you con- 
nect. 

(1) Disconnect. 

C Set FULLDUP OFF 
(<ESC>@ D0). 


Remember to short JP4 on the 
modem to enable the TNC-1 internal 
modem. This willalsorestore HBAUD 
(<ESC>H) operation for the internal 
modem if you are using the modem 
clock option. 


Enjoy 9600 bps operation with your 
TNC-1! 


First Impressions - 
Tasco’s TNCs 


by Bob Nielsen, W6SWE and 
Lyle Johnson, WA7GXD 


At the TAPR Annual Meeting in 
March, TASCO delivered a sampling 
of their TNC line and asked if we 
would test them and give them our 
impressions of the products. We 
received only limited documentation 
in English and haven't yet had the time 
to do a proper evaluation, but we have 
operated a number of the units and will 
give our initial impressions in this ar- 
ticle. Ina later issue of PSR we hope 
to do a more in-depth evaluation of 
these and other TNCs. 


Background 

TASCO is the TNC market leader 
in Japan. They are also a licensee of 
the TNC-2 technology, and this 
heritage is apparent in all the products 
we tested. TASCO was among the 
first to incorporate a BBS and "P-per- 
sistence” algorithms with the TNC-2 
cade. 


The TASCO product line is not 
available in the United States at the 
time this is being written. An earlier 
TASCO unit, the u21, was imported 
under the Heath label as the “Pocket 
Packet." 
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Current Products 

Units we evaluated include: TNC- 
u21, formerly sold in the U.S. as the 
Heathkit “pocket packet;” TNC-22; 
TNC-201; TNC-210, a later version of 
the “pocket packet;” TNC-211; TNC- 
223; TNC-231 All Mode Terminal: 
and TNC-24 MKT All Mode Terminal 
with PSK. Several of these units are 
based on highly-integrated Z80 
processors (84C015). By "highly in- 
tegrated” we mean these are single 
chips that include the Z80 CPU, Z80 
SIO, Z80 CTC and Z80 PIO as well as 
clock oscillators and watchdog timers. 


The user interface on all of these 
units is a variation of the TAPR com- 
mand set. Each was slightly different, 
with some being based on version 1.1.5 
and others on 1.1.6. Additional com- 
mands to support the mailbox, p-per- 
sistence, 16-bit alphanumeric codes 
for asian alphabets (and extensions to 
allow multi-mode operation in the case 
of the TNC-24 and -231) are included. 
Interestingly, the AXDelay and 
AXHold commands were missing on 
some of the units. A few of the special- 
ized commands were somewhat 
elusive to one who is not able to read 
Japanese. KISS mode is provided. 


The BBS mailbox, called a message 
board by TASCO, is quite similar in 
operation to that featured by Pac- 
Comm. Some of the commands are 
slightly different, such as (W)rite, 
rather than (S)end, and (File, in place 
of (L)ist. 


All units use an autobaud routine to 
set the serial port data rate. The All 
Mode units include front-panel push- 
buttons that can be used to set the serial 
port rate manually if you don’t want to 
autobaud. Several of the packet-only 
units have internal jumpers which can 
be used to select the terminal (up to 
19200 bps) and radio (for external 
modems) data rates. 


Most units (not the u21MKIID) also 
include a battery-backed real-time 
clock. Lyle set the clock up on the 
TNC-231 in March and it was within 2 
seconds after four months of operation 
without having been reset! 


Page 9 


Tasco Packet Terminal Node 
Controllers 


TNC-u21MKit 

This unit was formerly imported by 
Heath Company and sold in the U.S. as 
the "Pocket Packet." It is ap- 
proximately the size of a pack of 
cigarettes, with a plastic case and a 
RJ-11 type connector for the radio con- 
nection, as well as 2.5 and 3.5 mm 
jacks (and cables) for interfacing to an 
HT, a feature found on the other 
TASCO models. It has a 25-pin serial 
connector and a subminiature DC 
power connector. There is (barely) 
room for an internal battery. 


TNC-22 

This unit is pretty much the basic 
TNC of the product line. Itis about the 
size of a TNC-2, with the long dimen- 
sion running left to right. It has the 
standard 5-pin DIN connector for the 
tadio port as well as jacks for interfac- 
ing to an HT, and an in- line header 
type external modem connecter on the 
back panel. The back panel has a 25- 
pin serial connector and also has 
provisions for mounting a microphone 
connector and switch to provide for 
switching between voice and packet 
operation. 


TNC-201 

Functionally, this unit is quite 
similar to the TNC-22. The packaging 
is quite different, however, making 
much use of surface mounted com- 
ponents. It is about the length and 
width ofa TNC-2, but somewhat taller. 
There is an 8-pin mini-DIN connector 
on the back panel for connecting an 
external modem and a9-pin serial con- 
nector. The radio connection uses an 
8-pin DIN with the extra three pins 
brought to unused terminals on the cir- 
cuit board. The “normal” 5-pin DIN 
mating connector can be used with 
this, however. The back panel also has 
jacks for interfacing to an HT as in the 
other units. There is also a processor 
reset switch on the back panel. 


TNC-210 
This is an updated version of the 
Heath "Pocket Packet.” It uses the 
same size case, but upon opening it you 
are impressed with all the room inside! 
The older unit had two PC boards 
and the battery would only fit if the 
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phase of the moon was just right. The 
new unit is on a single PC board and 
the battery has lots of space around it! 


The rear panel now sports a DE9S 
(there is no such thing as a DB9...) as 
well as a standard-size 2.1 mm power 
jack. Nestled betwen these is a 
recessed reset bution. 


The front panel has the usual 5 
LEDs and an on/off switch as well as a 
mini-DIN connector for the radio port. 
This is a much better connector than 
the RJ-11C style used in the earlier 
unit, which was impossible to properly 
shield. Missing from this unit is the 
second switch which allows turning off 
the LEDs to conserve battery power in 
portable operation. 


At the Dayton Hamvention, Com- 
munications Specialists announced 
that they would soon be coming out 
with a new miniature TNC similar to 
the "Pocket Packet.” Is this it? We 
will have to wait and sce. 


TNC-211 

This miniature TNC is ap 
proximately the same size as the Pac- 
Comm Handi-Packet. It has an ex- 
truded aluminum case with metal front 
and back panels. There is a holder for 
4 AA-size batteries. A 6-pin mini-DIN 
connection is provided for the radio 
connection, in addition to the minia- 
ture jacks. Surface mounted com- 
ponents are used extensively, and there 
are two printed circuit boards. Some 
lucky attendees at the TAPR annual 
mecting received these units as door 
prizes, thanks to the generosity of 
TASCO. 


TNC-223 

This unit is identical to the TNC- 
201, except that itcontains an addition- 
al 128k of memory for the mini-BBS, 
expandable to 512K. 


Tasco All-Mode Terminals 

The TNC-24 and TNC231 include 
CW, RTTY, ASCH, AMTOR and 
WEFAX operation in addition to 300 
and 1200 baud packet. The TNC-24 
also includes a PSK modem for satel- 
lite use (it is a variation of the JAITUR 
design like that of the TAPR PSK 
modem). 


The TNC-24 has an LED bar tuning 
indicator that is quite easy to use (like 
the TAPR or MFJ units, you tune the 
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dot so it is mostly in the center). The 
TNC-231, however, has what has to be 
the most innovative tuning display we 
have seen in a multi-mode controller. 


A pair of 5x7 dot LED indicators are 
placed side-by-side to form a "screen" 
of 7 dots vertically by 10 dots horizon- 
tally. The internal modem is a filter 
type design, and the mark and space 
filters feed x and y analog-to-digital 
converters. The resultant display 
resembles what you would expect to 
see on an oscilloscope ("scope outputs 
are also provided). The display actual- 
ly has much greater resolution than you 
would expect from a 10x7 matrix, be- 
cause the human eye does some 
averaging. Asa result, you can actual- 
ly see phase shifts in the data, as well 
as sclective fading and other informa- 
tion. This indicator is by far the easiest 
to use and conveys the most informa- 
tion of any self- contained display we 
have scen to date. 


Most of the documentation is in 
Japanese, although we were provided 
with an early translation of the per- 
tinent portions of the TNC-24 operat- 
ing manual. The commands are the 
same for the TNC-231,so we were able 
to do some testing on HF as well as 
VHF. 


We didn’t evaluate the modems on 
any scientific basis, such as bit error 
rates at given signal to noise levels, etc. 
What we did do was connect them to 
radios and tune around on the HF 
bands and see what we could decode 
and what we couldn't. In general, sig- 
nals that were clearly above the noise 
floor of the radio and band at the time 
were quite copyable. Various types of 
QRM and QRN took their toll, but our 
impression is that the modem technol- 
ogy used is viable. 


The TNC-231 had the upper hand in 
ease of tuning due to its advanced style 
of tning indicator. The TNC-24 
tuned OK, but we were spoiled by the 
-231! 


The command syntax is different 
than we've come to expect for mode 
changes. For example, to select 
AMTOR-ARQ you type ’mode tty I’ 
for listen. You then have to be in 
converse’ mode to monitor the chan- 
nel activity. The two-argument syntax 
is unusual. Once we got used to it, 
though, it was no big deal. 
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TASCO includes a copy of 
“TASCO-TERM" a terminal program 
for IBM PC compatibics. It includes a 
number of features, including WEFAX 
display. We didn’t try the WEFAX 
modes. 


DCD 

The packet only TNCs and the 
TNC-231 use a TCM-3105 modem 
chip for 1200 bps FSK operation. You 
can’t run open-squelch or the DCD 
LED will stay mostly on, inhibiting 
transmission. There is a SOFTDCD 
command, but it appeared to suffer 
from considerable delay, partially 
defeating its effectiveness. Later tests 
will include the TAPR state machine 
DCD modification. The TNC-24 uses 
an AMD 7911 “World Chip” for its 
FSK modes and has a similar restric- 
tion. 


On the multimode units, the DCD 
indicator is used for CW reception, and 
atone is also generated in step with the 
decoded signal. The decoder scems to 
respond to band-limited noise, so if 
your rig has a CW filter you will get 
better results if you tum it off (as indi- 
cated in the manual)! 


Front Panel 

Both multimode units have a set of 
four buttons on the front panel. During 
reset, they can be used to force the 
TNC into a known configuration. 
During operation, they can be 
programmed for packet operation (for 
example, to connect to your local 
PBBS). They can also be programmed 
for a text string to be sent as CW. 


in addition to the tuning indicators 
mentioned above, there are LEDs to 
indicate mode, STA and CON, mail- 
box data to be read, PTT and PWR. 


The TNC-231 has a front-pancl 
power switch anda compensating filter 
adjustment for the HF-mode modem. 
The effect of turning this knob is quite 
visible on the 10x7 “screen.” 


The TNC-24 has its power switch 
on the rear pancl. 


Connectors 

The units (except the u21 MKII) use 
the standard 2.1 mm power connector. 
However, except for the TNC-22, they 
use positive on the barrel and negative 
on the lip, the reverse of what we ex- 
pect. Several of the units had a diode 
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bridge inside, making polarity unim- 
portant and those that did not had a 
series diode which would provide 
protection if you applied the "normal" 
power input. Several units came with 
a"powercube" supply which was rated 
at 100 vac input (the standard power 
source in Japan). These cubes seemed 
to operate satisfactorily over a period 
of several weeks at the standard 117 
vac U.S. line voltage. 


The multimode TNC radio connec- 
tors use an 8-pin DIN with the 5- pin 
subset wired as a TNC-2. This means 
you can use your normal TNC-2 ca- 
bling and it will work just fine. The 
extra pins are used for up/down AFC 
tracking when using the internal PSK 
modem in the case of the TNC-24. 
They are used for FSK + and - outputs 
in the case of the TNC-231. 


The TNC-231 also has a second 
radio port connector as well as a pair 
of jacks for connection to an HT. The 
port is selected by software command. 


The serial port on the TNC-24 uses 
a 25-pin D connector, the TNC-231 a 
9-pin. Both are wired as modems, 
using a straight through cable to con- 
nect to acomputer. The 9-pin models 
included a cable with a 25-pin male 
connector on the other end. This re- 
quired a "gender changer" adapter 
when used with the RS- 232 port of an 
IBM clone computer. 


Other 

The multimode units are about the 
same as a TNC-2 in physical size. The 
TNC-231 is set up similar to the TNC- 
2, with the long dimension running 
front to rear. The TNC-24 has the long 
dimension across the front panel; it is 
a shallow unit front to rear. 


The TNC-24 internally uses a mix 
of surface mount ICs on the bottom of 
the PC board and through-hole tech- 
nology ICsand discrete parts on the top 
of the board. If you get one of these 
units and open it up, be sure to remove 
the screw holding the 5- volt regulator 
to the bottom of the case before you 
attempt to remove the PC board from 
the chassis! (How do we know about 
this? Our lips are sealed!) 


The TNC-231 is a bit more complex 
to disassemble. Internally, it is a sur- 
face-mount design with ICs on both 
sides of the board. The top of the board 
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is dominated by two large, shielded 
inductors used in the HF modem. This 
is definitely not a unit we would want 
to woubleshoot or repair! 


Overall 

It has been very interesting for us to 
examine and operate these TNCs from 
our friends on the shores of the 
Western Pacific. TASCO has as- 
sembled a broad line of TNCs to appeal 
to almost every type of data com- 
munications operator in the Amateur 
world. We are gratified that their 
product line has its roots in the TNC-2. 
We hope to report in more detail on 
operational aspects of this equipment 
ina future PSR. 


More “first Impressions" To 
Come 

Ina later PSR we hope to report on 
the TMB-965 9600 bps modem and the 
HM-101 external HF modem (which 
has a modem and tuning indicator like 
the TNC-231). And we shoudn’t for- 
get the TASCO-TERM program 
provided with the TASCO TNCs. 


The Ottawa Packet group has intro- 
duced the "PI" card, a PC-plug in with 
an 8530 under DMA control for 56 
kbps operation. While we lack the 
ability to connect it to a 56 kbps 
modem (no modem!), we will report 
on this unitrunning under NOS at 1200 
bps. 

Interflex has provided us with a 
copy of PktGOLD for the AEA TNCs. 
We hope to report on it in an upcoming 
issue as well! 

We also have obtained Ramsey FX- 
series transceiver kits for 144 and 440 
MHz and hope to report soon on their 
operation with both 1200 and 9600 bps 
modems. 


Stay tuned to PSR! 
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PSK Modem Interface 


For KAM 


by Daniel Walter, M.D. 
NM3A @ K3PGB.EPA.PA.USA.NA 


I built the TAPR PSK 1200 Baud 
modem back in 1989 and I interfaced 
ittothe KAM unit. Ithas been working 
very well for three years now with all 
on versions from 2.7 through 

0. 


It is actually fairly simple, but get- 
ting all the information wasa real prob- 
lem. Kantronics, as usual, was no help 
at all. They said itcouldn’t be done, but 
being the dumb type, I went ahead and 
did it anyway. They also said that a 16x 
TXClock was not available, but itis, or 
at least a reasonable facsimile. 


First off, the kit should be built as 
fora TNC-2, The x16 TX clock (TXC) 
is available from the KAM’s modem 
chip. This is US, a TCM3105S. Pin 2 of 
US (R29) has a 19.11 KHz signal that 
is easily used as a TXC. The normal 
TXC is 19.2 KHz, but the modem does 
not seem to be upset by this minor 
difference. I have noticed NO opera- 
tions in which the modem does not 
work perfectly. 


Another anomoly is that the KAM’s 
DCD is inverted with respect to the 
TAPR standard. This can easily be rec- 
tifted within the PSK modem by use of 
(previously unused) U16a to invert the 
output of UL6f before it is sent to the 
TNC. To do this, connection #13, from 
U16 pin 12 to S4, is rerouted by con- 
necting U16 pin 12 to U16 pin 1 and 
U16 pin 2 is then connected to S4. 
(U16 pin 1 is tied to +5V, this must be 
disconnected by cutting the trace 
before making the other connections.) 
If you want to consider also using this 
on a TNC2/1, consider making this 
easily reversible with some type of 
connector. 


Table 1 is a list of the pin-outs for 
the KAM and the corresponding 
TAPR "standards." As you probably 
have noticed, there are very few pins 
that are the same as the TAPR stand- 
ards on the KAM. (Apparently, 
Kantronics doesn’t really want you to 
connect it to any other equipment!) So 
to connect the PSK modem to the 
KAM requires modifications to the 
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TABLE 1 
1 XENA- external CPU test 
2 (KAM memory control) 
3 CW control 
4 +5vde 
5 Chassis GND 
6 Audio<—radio 
7 (inverted) DCD-> TNC 
8 (inverted) OCD<—TNC modem 
9 extemal CPU ctrl (to pin 10) 
10 external CPU ctrl (to pin 9) 
1 CW-—>CPU (to pin 12) 
12 CWe—modem RxX (to pin 11) 
13 inverted CW-»CPU (to pin 14) 
14 inverted CWe—-RxX (to pin 13) 
15 TXDatae-TNC 
16 2PTT or 2IRTS-—>TNC modem 
17 RXData—TNC 
18 RXDatace—TNC modem 
19 TXAudio—TNC modem 
20 TXAudio—>TNC AFSK buffer 
TABLE 2 
Wire 
1 cut trace to PAD 4 
2 cut trace to PAD 8 
3 ve 
4 ve 
5 cut trace to pin 6 
new wire to PAD 2 -2- red 
“2- black 
-2- shield 
6 cut trace to pin 5 
7 cut trace to pin 8 
new wire to PAD 4 -4- yellow 
8 cut "ace to pin 7 
new wire to PAD 8 -8- white 
9 cut trace to pin 10 
10 cut trace to pin 9 
11 leave traces as is 
no connection to PAD 1 -1- vc 
12 leave traces as is 
no connection to PAD 1 
13 leave connected to pin 14 
14 leave connected to pin 13 
15 leave trace to PAD 7 -7- blue 
cut all other connections 
to pin 15 and PAD 7 
16 nc 
17 leave trace to PAD 5 -5- green 
18 leave trace to PAD 3 -3- orange 
19 leave trace to pin 20 
cut trace to PAD 6 
20 leave trace to pin 19 
cut trace to PAD 6 6- brown 
- 2 inch wire to Molex 0.062" 
single connector mate or similar 
KAM R29/ use end which is closest 
(U5pin2) to CPU (U26) 2 inch wire to mating 
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DCD-—»TNC 
DCD<~TNC modem 


RTS— TNC modem 

? (to pin 8) 

7 (lo pin 7) 

TNC1/2 

TNC1/2 
TXClock—»TNC 
TXClocke-TNC modem 
RXClock-—> TNC 
RXClock—TNC modem 
GNO 

We 

RXO— TNC 
RXD—TNC modem 
TXData—TNC 
TXDataeTNC 


am 
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small PC board that connects to the 
modem disconnect header (K8 in the 
KAM.) Quite a few traces need to be 
changed. They are listed in Table 2. 
Each pin is traced to the PC pad and the 
color coded wiring that TAPR uses and 
the pin number of the 8 pin DIN jack 
that the PSK uses. 


Altemately, you may want to con- 
nect the wires directly to a 20 pin 
female plug and keep the small circuit 
board in case you want to use it to 
interface to another TNC in the future. 


In addition to the connector added 
to the KAM’s R29 (sce Table 2), three 
other minor modifications must be 
made to the KAM. The traces between 
pins 17 & 18 and 7 & 8 of the KAM’s 
modem disconnect header (labeled 
K8) must be cut. (Pin 1 of K8 is closest 
to R97.) Make sure that no other traces 
are cut in the process. The final 
modification is to add a 20 pin header 
to the KAM’s circuit board. Place iton 
the component side of the board. The 
cable can be routed out the back easily 
with a 1/4" notch in the upper edge of 
the back plate just between the HF and 
the VHF jacks. 


If you want to disconnect the 
modem and put the KAM in it’s 
original functional condition, all that is 
needed is to put two shorting connec- 
tors across pins 7&8 and 17&18 on K8 
of the KAM. 


I also added a power switch to the 
front panel on the right of the 
JOINT/SPLIT switch. This could be 
incorporated into the modem’s 
ON/OFF switch but it is rather tight in 
there. On the back panel, I placed a 
screw adjust 50K potentiometer in the 
RX audio line as suggested (connec- 
tions 9,10 on main board schematic). 
This allows me to fine tune the input 
level at the most comfortable audio 
output level of my rig. 


Another minor note is that the 
manual says an oscilloscope must be 
used for adjustment. As I had none 
available when I built it, I made do with 
a frequency counter, the PSK modem 
itself and a DVM. Between the three, 
perfect allignment was relatively easy 
to do. An oscilloscope later confirmed 
that it was not necessary! On the other 
hand, if you have a ‘scope... 


After 1 was all done, I found I 
necded a box to control all the packet 
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lines in my shack, so I designed and 
built one, but that’s another story! 


Software Library Update 


by Lou Nigro, KW7H 


In addition to supplying various kits and fimmware, TAPR maintains a library of 
packet radio-related computer software. Disks are currently available in 5-1/4 in. 
MS-DOS format for $2.00 each, and in 3-1/2 in. for $3.00 each, including mailing 
(slightly more for foreign orders). In the future, possibly formats for other com- 
puters will be added. The current library listing contains the following entries (of 
which some are two-disk packages in the 5-1/4 in. versions only; single disks in 
3-1/2 in.). Additions to the software library are always welcome, however we do 
request that they be submitted either by, or with the expressed permission of, the 
author. TAPR attempts to provide the latest versions of all software; updates are 
appreciated. TAPR reserves the right to screen any submissions and restrict the 
library content as necessary. Both freeware and shareware are acceptable. 


The following is a brief description of the current listings in the TAPR software 
library: 

1. APLINK - A concurrent AMTOR MBO and packet BBS system by Victor D. Poor, 
WSSMM. 

2/2a BB - A multiconnect packet mailbox program by Roy Engehausen, AA4RE. 
Requires the use of AEA or WA8DED host mode or G8BPQ switch software for operation. 

3. C-BBS - Packet BBS program written in C language. Originally writen by Hank 
Oredson, WRLI, current version by K3RLI and AG3F. 

4. EZPAC11 - A menu-driven NTS message formatter by Mike Imel. Disk also contains 
a copy of WA7MBL’s YAPP terminal program. 

5. MONAX - A program for monitoring a packet radio channel and gathering system 
statistics. Described in a paper (included on the disk) presented in the 6th ARRL Computer 
Networking Conference by Harold Price, NK6K and Skip Hansen, WB6YMH. 

6. Ham Comm - A DSP RTTY program with VGA spectrum display, O’scope, tuning 
indicator, all real time. Uses simple 1 chip interface, schematic included, all parts available 
at Radio Shack. Powered by serial por. 

7. PBBS lists - Master PBBS list compiled by W9ZRX. 

8. R95 - A conversion utility to permit tansmission of binary files by packet radio by 
Greg Jones, WDSIVD. 

9a ROSERVER/PRMBS - A packet radio BBS with telephone modem support by Brian 
Riley, KA2BQE. 

10 ROSE - The ROSE switch by Tom Moulton, W2VY. 

11/l1a KA9QNET - Executables and source code for the NET version of TCP/IP by Phil 
Kam, KA9Q, with enhancements by Joe Buswell, K5JB. 

12. WXN Weather Server - A multi-user weather server that nuns as an application on the 
G8BPQ switch. Uses the Heath ID-4001 Advanced Weather Computer for weather data. 
Includes PC user program that runs on a TNC2. 

13. TNC-1 source code - Sources for the TAPR TNC-1 firmware. 

14. TNC-2 Software notes - Notes on TNC-2 versions 1.1-O through 1.1.7 by Howie Stein, 
N2WX. 

15. WA7MBL BBS - Packet BBS system by Jeff Jacobsen, WA7MBL. 

16. WRLI BBS - Packet BBS system by Hank Oredson, WRLI. 

17. YAPP - A packet terminal program by Jeff Jacobsen, WA7MBL. Supports split- 
screen operation, ASCII and binary file transfer. 

18/18a INTRO TO TCP/IP - Much descriptive and reference information on TCPAP. 

19, LAN-LINK - Packet terminal program by Joe Kasser, G3ZCZ. Also supports the 
non-packet modes of PK-232, KAM and MFJ-1278. 

20. ARES/Data - A packet radio data base system for emergencies by Weo Moerner, 
WNG6I and Dave Palmer, N6KL. 

21/21a MSYS - A multiconnect BBS with telephone modem, terminal, node and TCP/IP 
support by Mike Pechura, WA8BXN. Requires KISS mode. 

22. G8BPQ NODE - A NET/ROM-compatible multiconnect software packet switch by 
John Wiseman, G8BPQ, which can be run standalone or in conjunction with a BBS package, 
ARES/Data or DX Cluster software. 
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Notes from the TAPR 
Office 


It’s July again... not the best part of 
the year to be in Tucson! The weather 
is very hot, and muggy. 


TrakBox 

Talking about other hot matters: 
Lyle, WA7GXD, has been very busy. 
He has completed the latest TrakBox 
code documentation, and made avail- 
able some very nice schematics. If you 
desire the latest code and its docs, send 
$10, and I'll ship it to you! We also 
have available a binary coded decimal 
switch available for $8 including ship- 
ping & handling. 


Deviation Meter 

I have been asked numerous times 
about the Deviation Meter. Is it avail- 
able? Suffice it to say that Lyle, be- 
sides having been out of the country on 
business trips, and working untold 
hours on the other TAPR kits, has 
simply not had the time to do further 
work on it. 


Annual Meeting Publications 

At our annual meeting we offered a 
10-Year TAPR Scrapbook. It contains 
black and white copies of pictures of 
people and events that have made 
TAPR what it is through the years. 
You may obtain a copy of this by send- 
ing $5. 


Wealso havea few copies icft of the 
10th Annual Meeting Proceedings, 
also at $5. Included in this are articles 
on: "Spread Spectrum (CDMA) in the 
Amateur Service," by Dewayne 
Hendricks, WA8DZP; “General Pur- 
pose Signal Processing Software for a 
Radio Workstation," by Mike Parker, 
KT7D, "9600 Baud Backbone Radio 
& Modem," by Mel Whitten, KOPFX; 
and “Advantages of a Bit Regenerating 
Repeater for Local Arca Networks,” by 
Lyle Johnson, WA7GXD. 


9600 bps Modem 

The KONG 9600 baud modem is no 
longer available, as the new 9600 baud 
kit is being offered instead. 


We have a much more readable 
schematic for the new 9600 bps 
modem. If you would like a copy of the 
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5 page set, please send me a large 
SASE with $0.52 postage on it. 


As you can see elsewhere in this 
issue of PSR, the interfacing work that 
many of you were waiting for has been 
done. We definitely want to thank 
Bob, KD7NM, of AEA, for the excel- 
lent work he did in interfacing the 
PK232MBX with the modem. It’s a 
pleasure working with you AEA, thank 
you! 


Another person we wish to thank is 
Bobby, K8KIK, for the loan of his 
PK232MBX to TAPR. It helped a lot! 


Volunteers 
I'm going to get on the podium 
again here... 


People tend to think that TAPR is a 
commercial outfit, with all kinds of 
money, paid technical staff, etc. 
PLEASE remember: I am the ONLY 
TAPR employce, with all of the REAL 
work that you are buying and benefit- 
ing from being done by people like 
yourself. They too, have busy work 
schedules, only so many hours avail- 
abic to them in their evenings and 
weckends, and families with only so 
much patience! These volunteers use 
their own computers, their own TNCs 
to interface things with, etc. So if you 
feel that TAPR is slow in taking care 
of your technical needs, let me suggest 
that you get together with people in 
your area, and see what YOU can fig- 
ure out. Document what you find, and 
we'll all benefit! 


Some fellows have done just that. 


Brian, KC6HPN, wrote an exten- 
sive paper on the 9600 baud modem, 
which really helped us all, Thank you 
Brian! 


Brian, WB6CYT, wrote up some 
very helpful information on the KING 
9600 modem kit, which shows which 
of the parts are actually necded, and 
also a way to improve clock and data 
recovery. If you desire a copy of this, 
please send an SASE. Thank you! 


There are others of you who have 
contributed information and feedback, 
for which we thank you heartily. By 
the way, we consider negative feed- 
back even more valuable (well... al- 
most as valuable...hi) as the warm, 
fuzzy kind. We far prefer you to gripe 
to us first, before airing it to the world! 
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An apology 

I want to apologize to Ron Apple, 
who when visiting our city did not get 
such “hot" hospitality. It happened to 
be a time when all of the volunteers 
here were either busy or out of town 
and it did not work out to call you as 
we should have. 


Back to a HOT topic! 

Our very able PSR editor has done 
himself proud. There is now a MRS 
Bob Hansen! TAPR wishes this out- 
standing couple all of the very best that 
life has to offer. 1 think that getting 
each other was a major step in that 
direction! 

For TAPR, 

Heather Johnson, N7DZU 


11th Computer 
Networking Conference 


The 1ith ARRL Amateur Radio 
Computer Networking Conference, 
hosted by the Radio Amateur 
Telecommunications Society (RATS), 
will be held at Fairleigh Dickinson 
University in Teaneck, New Jersey, on 
November 7, 1992. 


The deadline for receipt of camera- 
teady papers for the llth ARRL 
Amateur Radio Computer Networking 
conference is September 21, 1992. 
Those planning to submit papers for 
this ycar’s conference should contact 
Lori Weinberg at the ARRL (203-666- 
1541) for paper guidelines and/or an 
author’s package. 
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ARRL Board Votes to 
Squelch Automatic HF 
Digital Operations 


by Tom Clark, W3IWI 
W3IWI@ W3IWI.MD (packet) 
w3iwi@amsat.org (Internet) 


The month of July saw an incredible 
amount of activity pertaining to the 
continuation of the ARRL-sponsored 
STA (Special Temporary Authoriza- 
tion) which permitted automatic, unat- 
tended digital operation on the HF 
bands. 


By way of review, when the FCC 
adopted NPRM 85-105 it permitted 
unattended digital operation, which 
gave us the opportunity to build 
VHF/UHF packet networks. However 
this permission was not extended 
below 30 MHz. 


To extend the line-of-sight links to 
provide trans- and inter-continental 
extensions of the packet networks, in 
1987 the ARRL requested an STA 
from the FCC to allow a selected list of 
Amateurs the same priviledges on HF. 
Thus was born SKIPNET. 


The initial STA was for a period of 
180 days, and in 1988 the ARRL was 
granted an extension based on a letter 
to the FCC, which stated, in part: 

During the 180-day STA period, we 

were successful in collecting enough 

data and operating experience to 
show persuasively that, with 
suitable safeguards, automatic 
operation of packet radio stations 
below 30 MHz is feasible and in the 
public interest. ... The conclusions 
are that the operation has gone al- 
most without incident and that those 

few instances of introduction of im- 

proper traffic were dealt with effec- 

tively. 


.. the Digital Committee will con- 

sider wording appropriate to permit 

automatic operation of packet-radio 
stations below 30 MHz. It is our 
intent to petition for such rule chan- 

ges during 1988... 

In the early years of the STA, the 
ARRL took heat from established 
users of the HF spectrum because the 
packet operations had usurped por- 
tions of the already crowded HF bands. 
This criticism came from domestic 
sources (particularly the RTTY com- 
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RRL Commi ) Radio Digital C ik 


The ARRL Committee on Amateur Radio Digital Communications met at 
8:30 CDT on June 13, 1992 at the DFW Marriott Hotel, Dallas, TX. Ed Juge, 
W5TOO, Chairman presided and Vic Poor, W5SMM acted as recording 
secretary. In addition the following members were present: Tom Comstock, 
NSTC, Craig McCartney, WA8DRZ, Paul Newland, AD7I, and Dale Sinner, 
W6IWO. Bob Poirier, KODJ, was unable to attend. 


Comstock reviewed the role of digital communications in past emergencies 
including the Mexico City earthquake and hurricane Hugo. 


Poor reviewed the current state of the art of current and soon to be introduced 
digital modes and their impact on HF spectrum utilization. 


The Committee as a whole reviewed the responses from the Digital Survey 
conducted by QST and RTTY Journal. 


A lengthy discussion followed on all the issues raised in connection with the 
operation of unattended amateur HF digital stations. The recording secretary 
was directed to summarize these discussions and the unanimously approved 
recommendations to the ARRL Board in a separate report which is attached as 
a part of these minutes. 


Ed Juge, Chairman Vic Poor, Recording Secretary 


June 13, 1992 
The ARRL Digital Committee has been asked by the ARRL Board to study 


the issues related to use of automatic unattended control of amateur stations 
operating digital modes in the HF spectrum and to recommend what action the 
Board should take toward establishing permanent rules for such operation, if 
any. 


The Committee has carefully studied as many of the facts and opinions as 
were available within the Committee's resources. Data bearing on the question 
included: 

The results of the ARRL Digital Survey; 

Frequency usage and allocations in the U.S. and in other countries; 

The current state of the art for amateur HF digital modes; 

Potential abuse of unattended operation such as illegal third party waffic; 
The various competing interests for HF spectrum, particularly between 
existing digital modes; and 

Amateur operating practices and traditions. 


The ARRL Digital Survey 

The members of the Committee carefully studied the tallies of answers to 
the questions in the survey and read every written comment submitted by the 
respondents, The survey data showed that majority of respondents favored 
permanent authorization of unattended semi-automatic operation but limiting 
semi-automatic operation to sub-bands, and a substantial majority did not 
approve of unattended fully-automatic operation. 


A wide range of opinions and proposals were made in the comments attached 
to the survey, all of which were discussed and weighed by the Committee. The 
important issues raiscd are discussed below. 


continued... 
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munity) and from IARU member 
societies. 

Well, the situation continued in 
limbo, with the STA being renewed 
annually. To gather facts to assist the 
ARRL in proposing rules changes, the 
STA community conducted an in- 
depth survey of activity and forwarded 
it on to the ARRL. In advance of the 
1990 STA renewal, the ARRL sent a 
letter to the STA participants stating, 
in part: 

By now, you have heard that the 

League has filed a petition for rule 

making with the FCC seeking per- 

manent provisions for automatic 

RTTY and packet operation within 

certain HF segments. Meanwhile, 

ARRL Counsel Imlay, N3AKD, 

will request the FCC to extend the 

SKIPNET special temporary 

authority for a year or until per- 

manent rules are adopted. 


Perhaps it would facilitate under- 
standing and discussion of the issues 
if you have some of the background 
leading up to the decisions repre- 
sented by this petition. 


I know I’m preaching to the faithful 
by saying that we need automatic 
packet operation in the HF bands. 
Nevertheless, the two and a half 
years that the SKIPNET STA has 
been in effect has shown that (a) 
such operation is technically 
feasible, (b) the network operations 
can be orderly without commercial 
encroachment, (c) the spectrum can 
accommodate it without undue dis- 
placement of other operations, and 
(d) HF automatic packet operation 
performs a vital public service that 
has proven itself in day-to-day and 
disaster communications. It's clear 
thal virtually al] Amateurs have 
come to the same general con- 
clusions, albiet reluctantly in a few 
cases, and have enjoyed the mes- 
sage-handling service provided by 
the packet network. It is evident that 
the FCC thinks Amateur packet 
radio is a good thing, including auto- 
matic operation on HF, by virtue of 
their granting the STAs. Also, the 
FCC has made repeated requests for 
the Amateur community to propose 
some permanent packet rules with 
adequate safeguards against 
prohibited transmissions. 


Well, the proposed mules changes 
were unacceptable to the 
RTTY/AMTOR community who saw 
the STA as a sham. The ARRL con- 
tinued to take heat from the other 
IARU member societies. Unable to 
form a consensus, the situation has 
been in limbo ever since. As a result, 
the STA continued with annual 
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Digital Committee Report, continued... 


Frequency Usage and Allocations in the U.S. and other Countries 

It is no secret that available space is very limited in the HF specuum. 
Nowhere is that more evident than in the very popular 20 and 40 meter bands. 
The two oldest modes of operation, voice and c.w., have the lion’s share of the 
spectrum in those bands since they were in heavy use before there were any 
digital modes. The digital modes have simply "squeezed in the crocks” between 
already established modes of operation. Since the digital modes have become 
established they have expanded gradually, a little ata time, primarily into space 
occupied by c.w. operation. Frequencies near the edges of digital mode opera- 
tion continue to be shared by both digital and non-digital modes. 


Outside of the U.S., depending on the ITU region and the rules adopted by 
various administrations, digital operation for any given mode may not align 
with practice in this country and itdoes not seem possible to establish a sub-band 
plan that could be universally acceptable. It is simply inevitable that any band 
segment in the HF spectrum is going to be shared among differing modes of 
operation. This is not a new condition on the HF bands and has been accom- 
modated for decades. 


Available Spectrum Space In the H. F. Bands 

Since all current HF band space is actively occupied by one or another mode 
of operation and since no current class of user is willing to give up space for 
another, the Committee is operating under the assumption that whatever rules 
are proposed there will not be a sudden significant change in the way the bands 
are currently used (at least this Committee is not prepared to make any such 
recommendation!). The Committee believes that gradual changes will continue 
to occur but that these changes will be due to natural migration as a larger 
percentage of amateurs shift to digital from other modes of operation and from 
one digital mode to another. 


The respondents to the survey strongly opposed the allocation of sub-bands 
by rule. The Committee also believes that any attempt to specify by rule 
sub-bands for a class of digital operation would soon grow obsolete as patterns 
of operation change, more digital modes are introduced, and more users shift 
to digital modes. Instead, the Committee believes that the amateur community 
will need to adjust itself to continued sharing of the spectrum by various modes 
and that such sharing should be facilitated through the publication by the ARRL 
of recommended sub-bands for the various modes and that such recommenda- 
tions should be revised from time to time as operating patterns change. 


The Committee, as a subsequent action, will propose a revised band plan for 
consideration by the ARRL. 


In any case, the HF spectrum is severely limited, especially for digital mode 
operation, and modes of operation that improve spectral efficiency must be 
strongly encouraged. The Committee will undertake a study proposing, in a 
subsequentaction, voluntary technical standards which can be promoted among 
amateurs and vendors to significantly improve our current frequency usage. 


The State of the Art for Amateur HF Digital Operation 

While the current rules allow considerable latitude in what digital modes the 
amatcur community uses, the actual practice is somewhat limited. Current 
practice includes "RTTY”, a non-error-protected simplex mode, usually using 
the baudot code; “AMTOR", a partially error-protected half-duplex mode using 
the baudot code; "packet", an error-protected half-duplex mode using ascii 
code; and "PACTOR", an error-protected half-duplex mode using ascii code. 
In addition, a new DSP-based system has been demonstrated but is not yet 
generally available called "Clover" that is an error-protected full -duplex highly 
spectrum efficient mode. 
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renewals; the current STA extension 
expires the end 1992, 


Also in early 1991, the FCC caused 
additional heartburn for the packet 
radio network by citing a dozen east- 
coast stations (including W3IWI) for 
automatically forwarding an Anti-war 
bulletin (I still call this the 900- GATE 
affair), In that action, the community 
was informed that EACH packet net- 
work station was responsible for the 
content of EACH message that auto- 
matically passed thru his station. 
Clearly the FCC has a problem under- 
standing automatic operation within a 
network! 


At the summer, 1991 ARRL Board 
mecting, the Directors made a decision 
to split the functions of the old Digital 
Committee into two — a Digital Com- 
mittee to look after the operational 
needs of the entire digital community, 
and an Advanced Techniques Com- 
mittee to help design future systems. 
To my knowledge, the ARRL never 
publicized the membership of either of 
the new committees. 


Early in 1992, the ARRL an- 
nounced a survey of the needs of the 
entire digital HF world. The STA 
group was told that they would be sur- 
veyed scparatcly for detailed com- 
ments on STA operations. Dale Sinner, 
W6IWO through his publication RTTY 
Journal called on all the RTTY and 
AMTOR users to respond en masse. 


Imagine our surprise when, in early 
July the following ARRL Bulletin ap- 
peared: 

SB QST @ ARRL SARLBO58 
ARLB058 Digital news 

ZCZC AG80 OST de WIAW 
ARRL Bulletin 58 ARLB058 
From ARRL Headquarters 
Newington CT June 25, 1992 

To all radio amateurs 


SB QST ARL ARLB058 
ARLBO58 Digital news 


The ARRL Committee on Amateur 
Radio Digital Communication has 
reviewed the results of the January 
1992 QST survey on automatic un- 
attended HF operation of digital sta- 
tions, and has submitted recommen- 
dations for ARRL Board considera- 
tion at its July 17 meeting. 


A clear majority of survey respon- 
dents opposed fully automatic, unat- 
tended operation on HF. However, 
by a ratio of two to one, respondents 
endorsed semi-automatic operation, 
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As currently used, all of the above modes require approximately 500 to 1000 
Hz. of bandwidth per channel except packet which requires 2000 Hz. per 
channel. Effective use of that bandwidth is terms of character throughput varies 
considerably as a function of the protocol used and the channel conditions. 
Partly because of the requirement for 2000 Hz. of space per channel and partly 
because of the nature of the AX.25 protocol, the performance figures for packet 
are the poorest per unit of bandwidth of any of the currently used modes. RTTY 
and AMTOR are better, and PACTOR is better still. Clover promises to exceed 
the throughput per unit of bandwidth of any of the above modes. 


Tolerance to poor channel conditions also varies among the modes with 
packet having the poorest performance, RTTY next, AMTOR and PACTOR 
being very much better. 


Digital techniques for HF operation are improving and newer technologies 
such as PACTOR and Clover promise significant near- term improvements in 
spectrum utilization, throughput, and performance under difficult HF radio 
conditions. The current rules do not appear to have contemplated these new 
modes in the HF portion of the spectrum and the Commitice believes the rules 
require a modest change to encourage these and other new more effective digital 
modes and to promote operation in the narrowest possible bandwidth. 


Potential Abuse of Unattended Operation 

A few respondents to the Survey expressed opposition to any form of 
unattended operation because of possible illegal use of amateur bands for 
unauthorized third-party traffic, commercial purposes, or the support of illegal 
activities such as drug smuggling. 


The Committee is not aware of any pattern of such abuse nor does the 
Committee see any reason why illegal operation is not just as likely to occur 
directly between two attended stations as any other. The Committee did not 
consider this factor in making its recommendations. 


Competing interests for HF Spectrum Space 

The most difficult issue the Committee has had to deal with is the demand 
for spectrum space from the many different classes of users. Many of these users 
are sharing (somewhat unwillingly) the same space and each would like the 
others to vacate to other locations. 


The most critical frequency bands (at the moment!) are 20 and 40 meters. 


On 20 meters the frequencies above 14,100 kHz. have been traditionally used 
for DX voice and below 14,100 KHz. for c.w. and data, With the advent of 
packet, and the STA authorizing unattended packet operation, packet operations 
began above 14,100 Hz. and has gradually occupied the region of 14,100 to 
14,125 Hz. Due in large part to the fact that data is not allowed in this sub- band 
in some countries, packet operation has also extended downward into the band 
immediately below 14,100 attracting US operation in this sub-band as well. 
Non-US voice operators have taken exception to the use of the 14,100-14,125 
space and RTTY operators have taken exception to the use of the space below 
14,100. 


On the 40 meters packet operation began in the 7080-7 100 Hz. region where 
traditionally RTTY and AMTOR operators had been active. This has forced the 
RTTY and AMTOR operations further down into the dismay of c.w. operators. 
This picture is further complicated by the fact that outside of region 2 data 
operation must be confined below 7050 kHz. 


The situation on other bands, especially below 21 mHz., though not as 
critical as on 20 and 40 meters, have similarconflicts. The informal 'sub-bands’ 
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where there is a control operator 
present at one end of the circuit. 


The Digital Committee recommen- 
dations are consistent with the sur- 
vey results. The Committee is 
recommending that FCC rules be 
proposed to permit semi-automatic 
digital operation below 30 MHz, but 
not to permit fully-automatic opera- 
tion. Neither type of operation is 
ptesendy permitted, except under a 
special temporary authorization 
gtanted to ARRL that will expire 
next January. The recommendation 
includes language to protect other 
Amateur operations from inter- 
ference in the event of a malfunction 
of the unattended station. 


The Commitice also recommends 
that the use of unspecified digital 
codes on HF be allowed, with 
bandwidth limited to 500 Hz below 
28 MHz and to 2 kHz between 28.0 
and 28.3 MHz, to encourage ex- 
perimentation with more spectrum 
efficient systems. 


Finally, the Committee recommends 
greater efforts by the Leaguc to edu- 
cate Amateurs interested in HF digi- 
tal operations, and to develop tech- 
nical standards or guidelines for 
spectrum- efficient digital com- 
munications equipment. 


ARRL Directors are now studying 
the recommendations of the Digital 
Committee, in preparation for their 
formal consideration July 17. At that 
time, the Board will have the oppor- 
tunity either to adopt the recommen- 
dations, decline to adopt them, adopt 
them in modified form, or postpone 
consideration. 

A number of SKIPNET members 
said "Huh??? What the **** is hap- 
pening here?" Calls to our local direc- 
tors indicated that none of them had 
seen the committee report. Most direc- 
tors did not know who was on the 
Digital Committee, or who had ap- 
pointed the Committee members. One 
Director thought that I was on the 
Committee and called me for informa- 
uon. 


Well, we finally got a copy of the 
full report — please see the sidebar. 


After this appeared, telephones 
started ringing and the packet and 
Usenet channels became very busy, 
trying to find out what was happening 
and tying to influence the ARRL 
Board in advance of their July 17th 
meeting. Here are some samples: 


Luck Hurder, KY1IT at ARRL HQ 
said, in defense of questions about the 
Committee acting in secrecy: 
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used by the various modes are also somewhat fluid as propagation conditions 
change and usage shifts from one mode to another. 


The Committee does not believe that any subdivision of the bands by rule 
will best serve the amateur community in the long run. It also scems unlikely 
that any subdivision of the band by mode will work on a world wide basis 
because of the differences in the rules between regions and between individual 
administrations. Any subdivision of amateur bands by rule also imposes an 
unnecessary potential enforcement burden on the FCC. 


Amateur Operating Practices and Traditions 

Except in a very few special situations it has long been the tradition (and 
tule) that one amateur station must not willingly or knowingly interfere with a 
contract already in progress regardless of the mode of operation or the perceived 
importance of the communications in progress. It has also been a long standing 
tradition that no station or group of stations ’own’ a frequency. (Frequency 
“ownership” has admittedly become a practice on certain VHF frequencies, but 
this practice has never been established on the HF bands and the Committee 
strongly rejects the concept of doing so now.) 


On HF the use of sub-bands with various classes of operation gravitating to 
specific locations is largely self regulating simply by virtue of the fact that a 
Station occupying a frequency is not driven off the frequency by deliberate 
interference by a station operating another mode. (There are always isolated 
exceptions to this but it is not condoncd in the rules or by the vast majority of 
amateur operators.) As greater numbers of amateurs use a particular mode that 
part of the band becomes recognized informally as a mode-specific sub-band. 
There is always a significant overlap in the sub-bands between modes - packet 
sharing with RTTY, RTTY sharing with AMTOR, AMTOR sharing with c.w., 
and so on. The greatest conflicts come where the overlapping modes have 
significantly different bandwidth, i.e., AM vrs. ssb, packet vrs. RTTY. 


Types of Automatic Operation 

Two types of automatic digital operation are under consideration for use on 
the amateur HF bands. One is fully-automatic operation where messages are 
passed between amateur stations without any operator intervention and no 
operator may need be present at cither station. 


The other is semi-automatic operation where messages are passed between 
amateur stations with an operator initiating the contact from one of the two 
Stations. 


Both fully- and semi-automatic opcration is permissible today under the 
rules provided there is a control operator present at both stations. (Stations 
authorized under the STA may operate unattended.) 


Digital operation with one station functioning in a semi-automatic mode has 
long been a practice dating back to the ’60s. 


Fully-Automatic Unattended Operation 

The proposal to authorize fully-automatic unattended operation represents 
distinct departure from past practices. A clear majority of the respondents to 
the survey opposed any fully- automatic operation on the amateur HF bands. 


To authorize fully-automatic operation without restriction, as some of the 
respondents to the survey advocate, would seriously undermine the fiber of 
mutual cooperation that HF operation requires. The Committee rejects such 
operation as undesirable on its face. 


It was also proposed to authorize fully-automatic operation with restrictions, 
either to the frequencies allowed, to a few privileged stations, or both. The 
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The truth is that the list of unattended 
digital STA folks has been available 
for the asking since day one. All a 
person need do was ask. And it's still 
available to the public on the ARRL 
BBS as a downloadable file. 


Also untrue is the notion that we've 
not spouted forth with regard to what 
we've learned from the STA. In fact 
we put out an ARRL/W1AW bul- 
letin about it just this past week. 


We even went so far as to ask the 
STA participants (and all other inter- 
ested Amateurs) for their opinions 
on how we should proceed with our 
request to the FCC for rulemaking. 
Over 500 people responded. Not 
what you'd call a ’secret’ guys! 


To which Hank, WORLI responded: 


And we responded to the earlier poll 
... the response from the STA par- 
ticipants was to allow fully automat- 
ic operation, since there had been 
near zero problems with it. Many of 
us have not YET responded to the 
recent “popularity contest” poll that 
appeared in a recent OST - in my 
case, since I've not yet had a chance 
to READ that QST. 


Who responded? [to the QST poll) 
What is the breakdown of people 
with actual serious HF packet opera- 
tion? What did they cite as reasons 
for not allowing automatic unat- 
tended operation? Have the inci- 
dents cited (if any) been inde- 
pendently verified? 


... What do the survey results mean? 
We have no information that indi- 
cates the survey did indeed sample 
the information it was expected to 
sample. 


The digital committee did not poll 

the STA holders. Since the STA 

holders are the only hams with ex- 

ence in automatic unattended 

F operation, this seems a VERY 
serious oversight. 


Note that this recommendation, if 
implemented, will shut down HF 
forwarding, and will shut down HF 
gateways. 


The original intent of the STA was 
to discover if it was feasible to have 
automatic unattended HF operation. 
The results of the operations under 
the STA have shown that ie is 
feasible. The previous survey 

THE PARTICIPANTS OF 1 THE 
STA showed that there were no 
problems. 


I strongly recommend that the digi- 
tal committee do it’s homework. A 
survey in a single ham magazine is 
not likely to produce the information 
the committee needs to make a good 
decision. 
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committee saw no purpose in limiting the frequency bands alone since the 
number of stations that would attempt unattended operation would make the 
mode and allocated frequency useless to everyone. Limiting the number of 
participating stations was also rejected by the committee because there was no 
conceivable way to equitably allocate the privilege to specific stations nor was 
the committee willing to set aside any portion of the band to stations with special 
privileges. 


Fully-automatic operation, by it’s very nature is mode-specific and must 
own’ the frequency it operates on an cannot be effectively shared by other 
modes of operation. 


To authorize fully-automatic operation on the necessary mode- specific 
sub-bands raises serious problems. There are no likely sub-bands that can be 
used on a world-wide basis or that will not cause interference to other users 
under some circumstances. 


The only mode of operation that is currently a prospect for fully- automatic 
authorization is packet, based on the AX.25 protocol, using 2 kHz. channel 
spacing. This mode delivers the poorest performance with respect to spectrum 
utilization or survivability under adverse propagation conditions of any the 
digital modes currently in use. } The Committee does not believe that, if a 
protected mode-specific sub-band is to be authorized, that it should be a mode 
that is as inefficient in its resource utilization as current packet practice 
represents. Such an authorization will discourage the development and use of 
a more suitable mode. 


Further, the Committee does not believe that these is any service being 
provided by fully-automatic operation that is not also available by other means 
without the associated problems of fully- automatic operation. Nor does the 
Committee know of any reason why packet operation cannot also be operated 
in semi-automatic mode, there-by eliminating the need for a rule-mandated 
sub-band. 


Seml-Automatic Unattended Operation 

There are many reasons, however, why some form of automatic digital 
operation is desirable. It permits amateurs to exchange communications when 
there is a time difference between the operating times available to the two 
amateurs, and it permits the quick exchange of messages rather than taking air 
time with long calls and keyboard-to-keyboard operation. (This nota suggestion 
by the Committee that keyboard-to-keyboard is undesirable but simply that 
there are many cases where moving messages at machine speeds is more 
spectrum efficient and makes more frequency time available to direct keyboard 
operation.) 

It is very evident that some form of automatic operation is highly desirable 
when handling NTS and personal messages between amateurs through inter- 
mediate stations. This capability forms the very heart of the amateur 
community’s preparedness for emergency service. Respondents to the survey 
favored semi-automatic unattended operation over those opposed by a two-to- 
onc ratio. 


The Committee does recognize that there is some potential for interference 
using a semi-automatic unattended mode even as there is such potential in 
purely manual modes. However, so long as there is a control operator present 
at one end of the link, monitoring the progress of an exchange, such interference 
can be held to a minimum. The benefits of semi-automatic operation outweigh 
the risk of inadvertent interference. 
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And let’s publish some actual infor- 
mation: Who's part of the STA? Are 
they on air? Have they been on air 
for the duration of the STA? What 
have their experiences been while 
operating under the STA? 


The “secrecy” that folks are con- 
cemed about revolves around the 
fact that the information on WHO is 
in the STA, and WHAT has hap- 
pened with the STA has not yet been 
made widely available. For ex- 
ample, it might make sense to 
publish the list of stations involved 
in the STA in OST. There WAS one 
packet BBS bulletin listing the 
original stations (sent around by 
W2JUP). There has been NO infor- 
mation about the results of the opera- 
tion of the HF STA stations. 


With respect to that operation: | 
know of only ONE incident that 
might have caused unexpected 
QRM, etc. Cannot remember exact- 
ly when it occured (perhaps 19857). 
Hardware failure caused one of the 
STA stations to go key down. The 
operator was notified within one 
hour (at his place of work), and he 
corrected the problem. He losthis L4 
linear though ... 


Is there other evidence that unat- 
tended automatic operation has 
caused problems? Don’t bother to 
respond with “It *COULD* do....”. 
The STA has been in existance fora 
long timenow, anything that “could” 
happen has had it’s chance to hap- 
pen, and didn’t. 


And Carl, WAOCQG said 


Jay, WS7I said, quote “The ARRL 
Digital Committee has done a great 
job and put forth a recommenda- 
Gon that deserves wide support. It 
has done the study that the STA 
never did and the conclusion that it 
reached should be supportable by 
the Amateur Community.” 


Whether itdeserves widespread sup- 
port is dependent on what it says. 
We'll know that when we see it, 
won't we? Where is it available? I 
haven’t seen it on packet nor here. 


The only request that the STA par- 
ticipants have had to provide info. to 
ARRL that I am aware of was in 
November 1987 when Paul Rinaldo, 
W4RI, sent a letter requesting 
specific details as to amounts, types 
of taffic handled and general opera- 
tional questions. Those details were 
included in a letter on January 5, 
1989 from Mr. Dave Sumner, 
KIZZ, to Mr. Ralph Haller, Chief, 
Private Radio Bureau, FCC, request- 
ing a further extension of the STA 
term. It stated that the lessons 
learned are: 
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The Committee believes that in view of the long successful history of 
semi-automatic operation that authorizing unattended semi- automatic opera- 
tion is in the best interests of the amateur community. 


RECOMMENDATIONS 
I. Unattended fully-automatic operation of amateur digital stations should 
not be authorized below 30 mHz. 


II. The FCC rules should be amended to allow unattended semi- automatic 
operation of digital stations on any frequency on which digital modes are 
authorized. Unattended semi-automatic stations may not initiate a contact, 
either with another station or via an undirected broadcast. An operator initiating 
acontact with an unattended siation must first ascertain that no interference will 
be caused to existing communications, and must monitor the progress of 
communications. If it becomes evident that the communications with an unat- 
tended semi-automatic station is interfering with other amateur communica- 
tions then the link with the semi- automatic station must be discontinued. An 
unattended semi- automatic station must be equipped with a time-out timer to 
insure that no signal is transmitted longer than five minutes in the event of the 
malfunction of control equipment or the loss of contact with the initiating 
station. Suggested wording for such an amendment is included in the appendix. 


Ill. The FCC rules should be amended to allow the use of modem- dependent 
codes for the purpose of efficient data compression and error control on HF 
radio channels. The bandwidth of such signals should be restricted to 500 Hz, 
below 28 mHz, and 2000 Hz. between 28.0 and 28.3 mHz The appendix to this 
report suggests specific wording for the recommended rule change. A station 
using a modem-dependent code must still comply with 96.119 Station Iden- 
tification. 


IV. The League should publish a comprehensive tutorial-style operator's 
guide for HF digital operations clearly defining acceptable operating practices. 
Such a manual would delineate currently used informal sub-bands for the 
various modes and styles of operation, and the good operating practices that are 
required for effective mutual cooperation and coexistence. This Commitice will 
make specific recommendations for the content of this guide. 


V. The League should publish technical standards or guidelines for the 
characteristics of signals gencrated by digital mode stations for the purpose of 
achieving the best possible use of the HF spectrum. QST should be used as a 
forum to educate that amateur community on the benefits and means of 
achieving acceptable signal quality and should review the technical charac- 
teristics of digital mode products with respect to published standards. This 
Committee will make specific recommendations for these technical standards. 


APPENDIX A 
The following is suggested wording for an addition to Part 97 authorizing 
unattended semi-automatic digital mode operation. 


97.3 Definitions 


() Unauended Digital Station - A station in the amateur service using an RTTY 
or data emission that is operated without a control operator present. 


97.216 Unattended Digital Station 


(a) Any amateur station licensed to a holder of a General, Advanced or Amateur 
Extra Class operation license may be an unattended digital station. 


(b) An unattended digital station may operate on any frequency below 30 mHz. 
that is authorized for RTTY or data emission for the class of operator license 
held. 
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“a. The system works, moves traffic 
and, with careful frequency selec- 
tion, can provide a public service 
without unduc interference to other 
Amateur activities. 


“b. Network management and con- 
tro] are necessary. 


“c. Accountability for traffic must be 
with the station introducing it into 
the network; accountability at relay 
points is not practical. 


“d. Packet is not compatible with 
other modes and needs separate fre 
quencies; carrier sense is not ade- 
quate to protect against interfer ing 
with other modes on HF owing to 
transmission impairments, hidden 
station effects, etc, 


“e. Frequency stability needs to be 
on the order of 10 Hz. 


"f. Protocols need improvement, and 
new capabilities are needed. 


“g. Modems need improvement. 


“h. Watchdog timer (to disable the 
transmitter automatically in the 
event of amalfunction) are essential. 


"i. Stations need to change frequen- 
cies in accordance with propagation 
conditions to improve efficiency, 
reduce retries, and free up frequen- 
cies for other users. 


“j. While a 200-watt power output 
has proven adequate for many 
domestic paths, there is no justifica- 
tion for a blanket 200-watt limita- 
tion.” 


So, that’s the kind of stuff learned 
during the STA, as reported to FCC 
by ARRL. Snuff learned from real 
life experiences. 


I think time is too short before the 
Board of Directors meeting to get 
wide-spread distribution of the 
document and understand it. There- 
fore, I have urged our local Director, 
Howard Mark (WOOZC) to either 
vote to table it or refer it back to the 
committee for inclusion of inputs 
from the STA participants. 


Quoting from comments by NO8M: 


The prohibition of automatic HF for- 
warding will result in a drastic and 
damaging affect on the Amateur 
radio networks that now exist. This 
is exactly what the ARRL Digital 
Committee is proposing. The text of 
their recommendation is circulating 
on other networks and on many 
PBBSs as a separate message. It is 
also available on the Cleveland 
Hamnet BBS, 216-942-6382. 


There is little doubt that the HF net- 
work as we now know it will col- 
lapse Few, if any HF Sysops now 
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(c) An unattended digital station may only use those RTTY or data emissions 
authorized by 97.305 and 97.307. 


(d)} No unattended digital station may initiate a contact with another station or 
may broadcast any undirected signal. 


(e) The transmitter of an unattended digital station must be equipped with a 
time-out timer that will insure that no signal is transmitted for longer than 
five minutes in the event of the malfunction of contro! equipment or loss of 
contact with the initiating station. 


(f) Any amateur operator initiating contact with an unattended digital station 
must first ascertain that no interference will be caused to existing com- 
munications, must be present for the duration of the contact, and must 
discontinue the contact if it becomes evident that communications with the 
unattended digital station is interfering with other amateur communications. 


APPENDIX B 

To encourage improvements in digital mode communications and especially 
to improved spectrum utilization on amateur HF bands Part 97, 97.307 (f) (3) 
and 97.307 (f) (4), should read as follows: 


(3) ARTTY or data emission using a specified code listed in 97.309 (a) of this 
Part may be transmitted. The symbo! rate must not exceed 300 baud, and for 
frequency-shift keying, the frequency shift between mark and space must 
not exceed 300 Hz. A RTTY or data emission using an unspecified digital 
code under the limitations listed in 97.309 (b) of the Part also may be 
transmitted. If an unspecified digital code is transmitted the authorized 
bandwidth is 500 Hz. 


(4) ARTTY or data emission using a specified code listed in 97.309 (a) of this 
Past may be transmitted. The symbol rate must not exceed 1200 baud, and 
for frequency-shift keying, the frequency shift between mark and space must 
not exceed 1 kHz. A RTTY or date emission using an unspecified digital 
code under the limitations listed in 97.309 (b) of the Part also may be 
uansmitted. If an unspecified digital code is wansmitted the authorized 
bandwidth is 2 kHz. 


operating will participate after the 
banning of automatic forwarding. 
(Ask one.) Hence, the same network 
that now relays the far majority of 
health and welfare, NTS and per- 
sonal mail will close. 


At this same time, the possibility of 
future enhancements and ex- 
imentation with a data network 
onall but the local scale will become 
so limited that the potential for ad- 
vancement will be all but lost. 


Years of a highly successful STA 
operation are being ignored, Advan- 
cements that have come from this 
experimentation such as Clover and 
Pactor are being ignored. Massive 
amounts of traffic handled during 
emergencies is being ignored. 


Instead, we are treated to page after 
page of suggestions based not on 
these many successes but on 
speculation and suspicion of 
problems that do not exist. Situa- 
tions that have not occurred. Pages 
after page of pretend that mocks the 
reality so easily shown by the net- 
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works that are real, that exist, that 
prove that it works, 


For years upon years, the staff of 
Newington has chosen to ignore and 
belittle the advances that have been 
made. Caught once in this activi ty, 
the prior Digital Committee was 
abandoned as an embarrassment. In 
its place were put tokens designed to 
meet a demand. The FCC, weary of 
waiting, publicly scored the ARRL 
with the announcement that they 
best get off their derrieres and move 
to propose rules for the termination 
of the STA. To this end they begin 
their fight to build a case able to 
ignore the fantastic dedication and 
labor easily shown by today’s net 
works. 


Should this event occur it will be 
years before the damage can be un 
done. This trend will only end and 
reverse if the Directors see the folly 
this Committee (and the staff at 
Newington who chose them) is per- 
petrating. 


Please, contact your Division Direc- 
lor and request that the recommenda 
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tions of the Digital Commiuee be 
abandoned. In mid-July they will 
have a meeting in order to take ac- 
tion on this matter. Your Director's 
information is available inside the 
cover of QST. Also please contact 
your Section Manager. Your Section 
Manager has an ear to your area and 
a voice in Newington. 


And I circulated this long diatribe on 


July 11th: 


The ARRL Digital Committee has 
filed a report to be voted on by the 
ARRL Directors in their meeting 
7/17 concerning the STA which per- 
mits automatic, unattended HF digi- 
tal operations. This STA has been 
hanging around for a number of 
years as an un-reconciled thorn in 
everyone’s side. 


This represents some of my personal 
comments on the proposal by the 
ARRL Committee on Amateur 
Radio Digital Communications 
dated June 13th. 


I find the Committee’s report to be 
interesting. I agree with part of it. I 
find parts of it suffering from tech- 
nical errors. I find anumber of places 
where assertive “God's truth” state- 
ments are made based on what I 
consider to be inadequate/incom- 
picte/questionable evidence and/or 
circular logic. 


The report conveys an aura which is, 
in essence: "let's flog packet” which 
J think is unfortunate, and tends to 
put some of the community immedi- 
ately on the defensive, My personal 
belief is that the desirable systems 
for the future are different from any 
of the current techniques, and will 
draw on the good/bad experience of 
each. Regarding new techniques, | 
am pleased to see Clover and Pactor 
represented; too bad several of the 
other new/proposed techniques 
were ignored. 


I find cach of the techniques to be 
discussed as a “black-box” based on 
perceived performance, with lots of 
apples vs. oranges comparisons. By 
way of example, the 
strengths/deficiencies of a particular 
class of modem technology are not 
separated from issues of error cor- 
rection, link-level data protocols, 
high-level messaging/networking 
protocols or number of people shar- 
ing a given frequency. 


From the packet standpoint, it is un- 
clear whether any distinction is 
made between “open” operation 
(BBSs open to all users) and 
“closed” (regulated, limited mem- 
bership) dedicated networks. 


The survey “vote” seems to have 


been based on counts of individual 
responses. This may give an incom- 
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piete picture. By this scheme, the 
"closed" dedicated HF networks 
(both packet and amtor) get only one 
“vote” per station when in point of 
fact, they handle messages from 
many people. I also note that, be- 
cause of the way in which the survey 
was announced and advertised 
{heavily promoted in the RTTY 
Journal, but with no specific te- 
quests to the HF Net Managers to 
submit statistics), many of the 
sysops of the “closed” network sta- 
tions didn't respond with enough in- 
formation. 


Let me note my personal credentials 
to comment on these various points. 
First, I have been an active member 
of the present STA since the begin- 
ning. T operate two “dedicated” 
“closed” HF Packet ports (14109 
and 21097), My HF + VHF/UHF 
system acts only as a network mail 
forwarding node and has no direct 
users, 


The W3IWI mail switch handles 
8000-12000 messages per month. 
Although NTS activity has 
decreased recently, my system has 
“made BPL” more than 20 times. My 
two HF ports typically handle 25- 
100,000 bytes of user-generated 
packet mai] each day. 


I have been active in designing and 
building the Amateur digital satel- 
lites to provide additional channel 
capacity to the world-wide network. 
Thave been involved in the develop- 
ment and design of several of the 
pieces of hardware in common 
usage including the TNC], TNC2 
and 1200 baud PSK modem. I have 
been involved in developing DSP- 
based techniques for improving 
link-level perfcrmance. I have done 
research in quantifying the effects of 
multi-path on HF digital links and in 
developing the digital protocols. 


Now to some specific points con- 
cerning the committee report: 


1. The meeting was held June 13th. 
Tt was July 8th before I was able to 
get a copy for comment, and it is 
only a week to get comments to the 
ARRL BoD. I wonder why the docu- 
ment was kept “secret” until it is 
(almost) to late to lobby the Direc- 
tors? My local Director (W3ABC) 
had also not scen a copy and phoned 
me today asking what I knew about 
it. 


Along similar lines, I wonder who in 
the community the committee dis- 
cussed the issues with? Among the 
folks I know operating HF packet 
systems under the current STA, and 
among the folks who are currently 
writing code to make improvements 
to the present sysiem, and among the 
folks who are trying to improve 
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modem technology, no one was con- 
tacted. I think some grievous errors 
and misconceptions could have been 
corrected if only people had asked! 


2. Spectrum usage: In the report the 
committee states 


“In any case, the HF spectrum is 
severely limited, especially for digi- 
tal mode operation, and modes of 
operation that improve spectral ef- 
ficiency must be strongly en- 
couraged. The Committee will un- 
dertake a study proposing, in a sub- 
sequent action, voluntary technical 
standards which can be promoted 
among Amateurs and vendors to sig- 
nificantly improve our current fre- 
quency usage.” 


Good, I'm glad to see that 
philosophical statement. Actually 
efficiency needs to also be measured 
in a second domain -- time. Any 
network needs to be judged on the 
basis of objective criteria like 
bits/day/kHz, not just occupied kHz. 
The committee then goes on to state: 


"The State of the Art for Amateur HF 
Digital Operation While the current 
rules allow considerable latitude in 
what digital modes the Amateur 
community uses, the actual practice 
is somewhat limited. Current prac- 
tice includes "RTTY”, a non-error- 
protected simplex mode, usually 
using the baudot code; "AMTOR", a 
partially exror-protected half-duplex 
mode using the baudot code; “pack- 
et", an error-protected half-duplex 
mode using ascii code; and “PAC- 
TOR”, an error-protected half- 
duplex mode using ascii code. In 
addition, a new DSP-based system 
has been demonstrated but is not yet 
generally available called “Clover” 
that is an error-protected full-duplex 
highly spectrum efficient mode.” 


I wish to note that "CLOVER" is not 
the only “DSP-Based” technology 
currently being developed. I also 
note that Clover is the only “mode” 
listed (but not the only one under 
development) where new modem 
technology is being developed. The 
other techniques cited use nearly 
identical FSK implementations. 


“As currently used all of the above 
modes require approximately 500 to 
1000 Hz. of bandwidth per channel 
except packet which requires 2000 
Hz. per channel. Effective use of that 
bandwidth is terms of character 
throughput varies considerably as a 
function of the protocol used and the 
channel conditions. Partly because 
of the requirement for 2000 Hz. of 
space per channel and partly because 
of the nature of the AX.25 protocol, 
the performance figures for packet 
are the poorest per unit of bandwidth 
of any of the currently used modes.” 
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1 wonder what kind of strange weed 
the authors were smoking when they 
decided that packet REQUIRES 
2000 Hz of bandwidth. The current- 
ly used channels on HF happen to be 
spaced 2000 Hz, but that was simply 
done for convenience. With 300 
baud data superimposed on a 200 
kHz shift. the REQUIRED 
bandwidth is about 500 Hz. Even 
given mortal receiver and modem 
filters, 1 kHz channel spacing would 
be adequate, With high performance 
receivers and a DSP madem (TS950, 
DSP2232) running the current 
BELL 103A standards, I have 
demonstrated that 750 Hz spacing is 
more than adequate. 


3. Channel Throughput. The Com- 
mittee chose to make this statement: 


“a. RTTY and AMTOR are beuer, 
and PACTOR is better still. Clover 
promises to exceed the throughput 
per unit of bandwidth of any of the 
above modes.” 


I would like to see the factual jus- 
tification for justifying the statement 
about packet. One major difference 
between the techniques that must be 
normalized to make such definitive 
claims is that the packet channels 
have several users on a frequency at 
a fiven time. Is the claim that ONE 
STATION's throughput is poorest, 
or is that the total channel through- 
put, considering frequency re-use is 
poorest? 


In the case of packet, are they refer- 
ring to the "free-for-all" packet 
channels wherein the BBSs operate 
“open” or to the “closed” networks 
which limit membership in an at- 
tempt to minimize congestion, or to 
both? 


This set of sweeping statements, 
made to sound authoritative but 
lacking factual support are 
PRECISELY the type of apples vs. 
oranges rhetoric that some people 
have used to try to incite packet vs. 
rity vs. amtor “wars.” These rhetori- 
cal statements sweep under the ng 
that the performance differences 
arise because of several factors. 


4. Logic Flaws! 


Why are these statements flawed? 
First, the radio side of the HF chan- 
nels cannot be simply modeled. 
Gaussian noise is the least of the 
problems. QRM and QRN must be 
considered. Even more severe are 
effects of multipath. Papers at the 
ARRL Networking Conferences 
and in QEX by VE3JF, KB1JY and 
W3ITW1 as well as in the professional 
literature have demonstrated that on 
links well below the MUF, multipath 
causes significant intersymbol dis- 
tortion at data rates about about 75 
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baud (symbol times shorter than 
about 15 msec). On “long-path” 
links near the MUF, rates well above 
300 baud can be supported. The 
packet world has been tarred and 
feathered about performance when 
in fact the modem/data rate chosen 
for a the links were in error. I’ve had 
trouble copying 110 baud RTTY 
from W1AW on 80M. That is the 
fault of RTTY -- it’s the attempt to 
use symbols that are too short to 
propagate thru the ionosphere. 
Proper application of improved 
adaptive modem technology (like 
Clover, like the idea ] presented at 
the 7th Networking Conference, and 
like the ideas proposed by VE3JF 
and N4HY) will benefit all the tech- 
niques. 


Modems and the ionosphere are but 
one link-level issue. A second con- 
cerns the lowest level protocols. 
Clearly the error correction that 

R uses is a major key to its 
good demonstrated performance. In 
essence AMTOR is packet-like with 
a frame length 20 bits. HF packet 
uses frames 500-1000 bits long with 
only error detection; jt only works 
when bit error rates are below 
1x10e-3 -- arather stringent require- 
ment for marginal HF paths. Pactor 
and Clover make an effort to bridge 
this gap, as do other link-level 
protocols proposed and being 
developed by N4HY, VE3JF, and 
W3IWI 


At a higher level, another protocol 
issue which makes the “my techni- 
que is better than yours” arguments 
difficult is the time domain. RTTY 
and AMTOR tend to require that 
only one link (i.e. QSO) be in 
progress on a frequency at a given 
time. Packet (and Pactor) allow for 
time-domain channel sharing. This 
is an advantage when the different 
sessions occupying a given frequen- 
cy can hear each other. When they 
can't, the “hidden terminal” problem 
occurs and everyone suffers when 
the different users step on each 
other. The regulated, established HF 
Nets attempt to deal with this by 
limiting membership and enforcing 
time slotting. Protocol enhance- 
ments involving backoff timers, 
prioritized “acks,” etc have been 
proposed and tested, but more 
development is still required. 


At still a higher protocol level, the 
present protocols all have weak- 
nesses. The current use of con- 
nected-mode AX.25 is flawed. 
NK6K, K&KA, KA9Q and W3IWI 
have all proposed datagram-based 
“broadcast” protocols (much like 
those used in the NK6L/K8KA 
PACSAT protocols) on HF. 


T have stressed these future develop- 
ments/augmentations to make a 
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point. The committee proposal tries 
to cast the present system in con- 
crete. It is flawed in its simplistic 
“automatic vs. semi-automatic” dis- 
tinction. As a case in point -- I can 
envision adaptive protocols that 
(like current AMTOR) “probe” a 
number of frequencies trying to find 
a path. Once a path is found, some 
information is transmitted, but not 
all of it makes it thru. Several hours 
later, the “probe” finds anew pathon 
a new band and some more data is 
transferred. Depending on the 
amount of information, this might 
take a whole day. The data (mes- 
sage) has been fragmented and can 
only be reassembled after it is 
received in its entirety. This seems, 
to me, to be an exciting technical 
development that only Amateurs 
could ‘b. But, unless the person at 
the manually-operated end of the 
semi-automated link is willing to sit 
at the rig for 24 hours, it REQUIRES 
automated stations. Why should we 
push the world (FCC, IARU, etc) to 
adopt “rules” which tie our hands? 


The committee report sort-of a 
with my statements about the future 
wends: 


“Digital techniques for HF operation 
are improving and newer tech- 
nologies such as PACTOR and 
Clover promise significant near- 
on kigolniyt on in spectrum 
utilization, ughput, lor- 
mance under difficult HF malseoe 
ditions. The current rules do not ap- 
pear tohavecontemplated these new 
modes in the HF portion of the 
spectrum and the Committee 
believes the rules require a modest 
change to encourage these and other 
new more effective digital modes 
and to promote operation in the nar- 
rowest possible bandwidth.” 


In the Jast sentence, | would again 
stress that bandwidth per se is only 
part of the issue, The number of 
users sharing x kHz of spectrum and 
the number of bytes they can send 
per minute (or hour or day) alsoneed 
to be part of the criteria. 


5. Interference: Pore the 
report (I won't quote specific 
sections) there is a lot of discussion 
about interference. Let us consider 
for the moment that digital techni- 
ques are intrinsically channelized. 
Packet operation assumes that there 
will be interference from other users 
on the channel. The hardware and 
software detect the other signals, and 
when problems occur, the user auto- 
matically slows down to share the 
channel. AMTOR has developed 
frequency hopping as a way to auto- 
matically cope with channel conges- 
tion. While malicious interference is 
morally and socially unacceptable, 
channel sharing (in time and/or fre- 
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uency) is aproven way to cope with 

¢ problem. Problems develop only 
when the modes are incompatible 
ras “assignments” are vio- 
ated. 


6, What the committee proposes and 
its implications: Again I quote: 


“The proposal to authorize fully- 
automatic unattended operation rep- 
resents distinct departure from past 
practices. A clear majority of the 
respondents to the survey opposed 
any fully-automatic operation on the 
Amateur HF bands.” 


How long is the integration time for 
the words “past practices"? Certain- 
ly fully automated unattended pack- 
ctoperations have been going on for 
at least 8 years! And I suspect that 
some of the automated AMTOR sys- 
tems now on the air are also running 
the same way. 


The Committee’s recommendations 
scem to be based on numerical 
replies. 1 doubt that the average 
packet user bothered to “vote” be- 
cause the survey was not addressed 
to him/her. But the <implications> 
of this action will have a marked 


“semi-automatic” (which I liken to 
being half-pregnant or having half a 
pair of pliers!) mode legally. I hope 
that someone else will step up to the 
task of providing the service I have 
prided myself in for the past 6 years. 


In anticipation of comments like 
mine, the committee states: 


“Further, the Committee does not 
believe that there is any service 
being provided by fully-automatic 
operation that is not also available by 
other means without the associated 
problems of fully-automatic opera- 
tion. Nor does the Committee know 
of any reason why packet operation 
cannot also be operated in semi- 
automatic mode, thereby eliminat- 
ing the need for a nile-mandated 
sub-band.” 


I am unconvinced. Who is correct? 
If you have any comments on these 
ideas I urge you to contact your 
ARRL Director immediately so that 
he can cast an informed vote during 
the ARRL BOD meeting next week 
(7/17). 73 de Tom, W3IWI 


quested to continue its study of the 
issue of unattended digital opera- 
tion, with the objective of develop- 
ing future recommendations for in- 
creased flexibility of operation of 
this class of station. 


It was then moved by Quiat, 
seconded by Kanode, to strike the 
text and substitute the following: 


That the ARRL petition the FCC for 
a Notice of Proposed Rulemaking to 
provide for: (1) Fully unattended HF 
digital BBS operations under 47 
CFR Part 97, subject to the follow- 
ing: (a) Data control--at the point of 
Origination, all bulletins would be 
held for SysOps’ review to screen 
out Part 97 violations, such as those 
having commercial or other inap- 
propriate or unlawful textual con- 
tent. (b) Equipment Control--all 
automatic HF BBS operators will 
include hardware, such as a 
telephone link or UHF/VHF link to 
shut down the HF port in case of 
awareness of, or reported, hardware 
malfunction. Additionally, locked- 
key sensors and over-temperature 
sensors shall be installed to shut 
down the HF port if the above or 


Well, the ARRL Board met. Here 
are extracts of the relevant portions of 
their minutes: 


other prohibited conditions are 
detected. (2) Digital transmission 
rates up to 1200 bauds shall be al- 


effect on them. 


In point of fact, a large fraction of the 


long-haul packet messaging outside 
a user's local area is carried on HF 
by automatic, unattended HF packet 
slations. Yes, some fraction is now 
being handled by the limited 
Amateur satellite resources the com- 
munity has built over the past few 
years; some fraction is handled by 
the (semi-)automatic AMTOR sia- 
tions; and some fraction is handled 
on non-Amateur (i.e. wire) links 
bypassing Amateur radio completc- 
y. 


The Implications: I'll speak for 
myself and ask the other operators 
on the HF networks to comment on 
their own views. W3IWI now hand- 
les thousands of user messages each 
month on HF under the aegis of the 
STA, operating automatically and 
unattended under the current STA. 
My professional commitments re- 
quire me to be away from home quite 
a bit. When I am away I Icave in- 
structions on how to kill the radio if 
a <technical> malfunction occurs, 
but the messages keep being sent 
automatically. Recently I was in 
DL/UA/OH/LA/SM for 3 wecks. 
Several thousand messages passed 
thru the HF port here. [ even sent 
mail from UA3/W3IWI back home 
thru the system. 


If the Committee’s recommenda- 
tions are adopted, or if some alterna- 
tive lo the present STA is not found, 
I will be forced to go QRT. I simply 
cannot operate in the ill-defined 
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32) Comstock, as Chairman, 
presented the report of the ARRL 
Committce on Amateur Radio Digi- 
tal Communications. The committce 
reviewed the role of digital com- 
munications in emergencies, the 
“state of the art" for digital modes 
and their impact on HF spectrum use 
and the responses from the digital 
survey conduc’ed by QST and the 
RTTY Joumal. The committee then 
examined at length all of the issues 
raised in connection with the opera- 
tion of unattended Amateur HF digi- 
tal stations. 


33) It was moved by Comstock, 
seconded by Heyn, that the General 
Counsel, with the assistance of the 
Exec VP and the staff, is authorized 
to prepare a draft Petition for FCC 
Rulemaking to permit the operation 
of a new von we! of Amateur sta- 
tion, “unattended digital station," on 
RTTY/data frequencies below 30 
MHz. Only Amateur stations under 
the active control of a control 
operator would be permitted to com- 
municate with unattended digital 
stations; unattended digital stations 
would not be permitted to engage in 
one-way communications; and ap- 
propriate safeguards would be re- 
quired to prevent unattended digital 
stations from causing harmful inter- 
ference to other Amateur stations. 
The draft is to be circulated to the 
Executive Committee for review 
and final approval before filing. Fur- 
ther, the Digital Committce is re- 
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lowed of HF Amateur bands from 
3-30 MHz. (3) Bandplanning within 
a maximum of 30 kHz of any 
Amateur band to allow safe 
bandwidth margins for 1200-baud 
transmission will be implemented 
by agreement and understanding 
within the Amateur Radio com- 
munity. 


After discussion, however, the mo- 
tion to amend was LOST. 
Whereupon, the question being on 

Comstock’s motion, the same was 

ADOPTED. Turnbull, Burden, Mc- 

Connell and Grauer requested to be 

recorded as voting no. 

I talked with Director Turnbull 
(W3ABC) after the meeting. He told 
me that Quait’s motion was very con- 
fused and was defeated by a vote of 
14-1, I gather that many of the directors 
didn’t understand the issues. He 
reported that no other director offered 
an alternative to Comstock’s motion 
and that it was passed. Turnbull further 
Stated: 

.. my position has been consistent 

for the past 4 years. There are two 

issues involved. 


FIRST - The need for a spectrum 
management policy (call it band 
planning, if you wish) that will be 
reviewed periodically and avoid 
some of the perceived chaos and/or 
incompatabitities. 
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SECOND - The need for automatic 
efficient information handling sys- 
tems where the content is the respon- 
sibility of the originator. 


Both items should be determined not 
only on the basis of current and fu- 
ture technical requirements 
developed by those knowledgable, 
but also from the responsible inputs 
of both the user and provider com- 
munities. 


So, the SKIPNET community is left 
in limbo, As of December the present 
STA will expire. Who knows what the 
FCC will decide. Most of the present 
STA stations (both packet and 
AMTOR) expect to shut down because 
they are unable to operate in the “half- 
pregnant” semi-automatic mode. Un- 
less the problem is solved, our only 
channel for trans- and inter-continental 
message handling will be via the satel- 
lites, or clse by routing everything thru 
Canada. 


To show the users what they are in 
for, the Colorado SYSOPS are staging 
a two-day hiatus, as seen in these com- 
ments from WOLJF: 


The following is one of many bul- 
letins sent to the BBS sysop’s in 
Colorado defining our short-term 
plan to open the eyes of the local 
users to our plight. Next weekend 
{Aug 1/2], the BBS stations are 
going to shut down completely for 2 
days. We are hoping that this will 
shock the users into appropriate ac- 
tion. In all actuality, we'll probably 
be called dirty names and accused of 
playing GOD; but we have to try 
oe drastic, as time is 
short. 


1 am not tying to influence you to 
do the same in your states, but simp- 
ly to let you know ONE of the things 
that CO is doing to further our cause. 
..73..Ed WO 


Bulletin to SYSOP @ COBBS fol- 


lows: 


I just had a long talk with WOGVT 
on the tele. He suggests, and quite 
properly so, that AFTER the 
weekend blackout (I may go longer 
on the local blockout) that we send 
a bulletin to ALL users that this is 
what can be expected after Decem- 
ber 31, 1992 UNLESS we get the 
ARRL Digital Committee, The 
ARRL proper and the FCC to 
change their course of action. He 
Says to also provide names, addres- 
ses for comments to the proper par- 
ties. I concur....g00d idea. We need 
to get the addresses of these folks. 
Do any of you have this informa- 
tion? I would send a similiar bulletin 
to the the users right now, but they 
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have no incentive at the present to 
petition these folks. Once they ac- 
tually see that their hobby is in 
jeopardy, “they will see with open 
eyes", to loosely quote a verse from 
the Bible. One thing that everyone in 
the BBS biz should remember is that 
when the STA expires, that’s it. 
There is NO unattended autofor- 
warding UNLESS the FCC modifies 
part 97. No matter what the ARRL 
recommends, we need to influence 
the FCC to see it our way. J have no 
idea how much the under- staffed 
FCC actually listens to the ARRL. 
Comments, please. 


Wynne, WOIUQ in Iowa sent me a 
note recommending: 


I do not think a slow-down or stop- 
page of service is a good idea, since 
it can easily backfire. In some areas, 
like Jowa, where the service is al- 
ready pretty poor, it may go un- 
noticed and that could be used as 
evidence that the system isn’t work- 
ing and isn’t needed. Besides, it is 
Negative and smacks of a lack of 
cooperation, like labor strikes aimed 
at the general public. 


Instead, I think we should take posi- 
tive action, and some possibilities 
are the following: 


(1) The STA group could respond 
directly to the FCC and deliver the 
results of the study promised by the 
ARRL, proving that unattended 
operations are feasible and do not 
cause interference. 


A sy bach separately petition 

or the unattended opera- 
ri we want, and it would be best 
if that could be done before the 
ARRL gets theirs in. 


(3) Petitions could be circulated at 
hamfests and club meetings. 


(4) An article on this could be writ- 
ten for QST (which they may or may 
not publish). 


(5) Get lots of people talking about 
this on packet. (I have seen only a 
few, poorly-thought-out bulletins, 
and that surprises me.} 


(6) Encourage letters to the ARRL 
and/or the FCC. 


(7) Appeal at a personal level to the 
FCC. "Bo you know anyone there?) 


(8) Apply pressure to the Board of 
Directors, as you suggested, citing 
their votes on this issue. 


It is also important to work together 
and coordinate our efforts. If I can 
do anything, please let me know. 


Ifand when the ARRL files with the 
FCC, then we will have the oppor- 
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tunity to comment. Here are some 
remarks from AD8I: 


After watching the diseracstul 
charade orchestrated by the ARRL 
power structure, the packed Digital 
Committee and the back room deal- 
ing by the Board of Directors, I have 
decided to let each of you know 
where I stand in the ‘automatic 
operation’ debate and let you know 
what I intend to do. 


will terminate *ALL* packet 

ations at 23:59z 31 December 

2 unless the FCC has acted to 
few full automatic operation for 
*ALL® classes of digital stations. 1 
will resume VHF-only operation of 
me OLE GENE SERY: R after 30 

ays. 


If the ARRL presents a proposal to 
the FCC that discriminates against 
ANY class of automatic digital 
operations, I will file a very strongly 
worded set of comments in opposi- 
tion. Those comments will be based 
on our collective experince under 
the STA. They will state that there is 
no technical justification to prohibit 
fully automatic operation of digital 
stations below 50 MHZ. They will 
state that there is no valid reason to 
permit only semi-automatic 

tion. Finally, they will recommend 
the COMP PROHIBITION 
OF ANY AMATEUR OPERA- 
TION IN WHICH THERE 1S NO 
CONTROL OPERATOR PHYSI- 
CALLY PRESENT AT THE 
LICENSED CONTROL POINT. 


As far as I am concerned, the ARRL 
elite can not have it both ways, either 
automatic operation is OK for 
everybody or it is not right for 
anybody. It is time to make a stand 

... time to expose the emperor's new 

clothes for what they really are! 

The other approach is to make a 
preemptive strike and directly petition 
the FCC for a Notice of Proposed 
Rulemaking before the ARRL does. 
This could be done by concemed in- 
dividuals, or it could be done by TAPR 
as the premier packet radio organiza- 
tion. If the TAPR membership feels 
Strongly about this issue, let us know 
ASAP. 


Thanks to all who have made com- 
ments in the past month. Sorry | 
couldn’t include them all. Much of the 
material included in this report was 
taken verbatim from the inputs, so 
don’t blame me for any errors in the 
quotes! 
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A Proposal for 
Automatic Operations 
on HF 


by Lyle Johnson, WA7GXD 


In late May, the ARRL Digital 
Committee made a recommendation to 
the ARRL Board recommending 
against "fully" automatic operations 
(¢.g., Operations in which an unat- 
tended station establishes contact with 
another unattended station) while 
sanctioning “semi” automatic opera- 
tion (e.g., operations in which an unat- 
tended station only responds to the es- 
tablishment of a contact, requiring an 
operator to be present at the station 
which establishes the contact) on our 
HF bands where data communications 
are authorized. 


This proposal explores a possible 
alternative to the Digital Committce’s 
recommendation. 


The Issue: Fully-Automatic 
Operations 

The issue is not whether packet is 
the "right" mode, or even a good mode, 
for such operations. It is not whether 
AMTOR or RTTY or PACTOR or 
CLOVER are preferable. I believe the 
issue is whether fully-automatic HF 
operations are feasible, or even 
desirable. My understanding of the is- 
sues leads me to believe that the STA, 
which expires in December of this year 
and which the FCC has indicated will 
not be renewed, has proven that fully- 


automatic operations on HF are 
feasible from a technical standpoint. 


However, the STA has provided for 
operations by a "chosen few" and has 
resulted in loud, though perhaps not 
Numerous, complaints from other 
operators. 


The Objections To 
Fully-Automatic Operations 

The essence of the objections of 
which I am aware are: 


1) Foreign phone operators on 20 
meter SSB resent the intrusion of 
automatic mail forwarding in the 
region of 14.100-14.115 MHz; 


2) The 40 meter band, which is also 
workhorse spectrum, is different in 
Region 2 than it is in Regions 1 and 
3, and this has lead to complaints. 


3) If fully-automatic operations arc 
generally authorized and this some- 
how lIcads to a deterioration in 
spectrum accessibility by other 
traditional users of those frequen- 
cies, it will be very difficult to “put 
the genie back in the bottle." 


4) There is no fair way to allow only a 
few Amatcurs to run fully automat- 
ic stations and exclude others who 
might want to run such stations. 


The other objections I have heard 
are related to the perceived perfor- 
mance of packet versus other modes 
and are therefore irrelevant to the 
central issue of fully automatic opera- 
tion. 


Membership Application 


The Grand Experiment: The 
STA 

The STA, which has been in place 
for anumber of years, allowed a certain 
number of Amateurs to participate in 
an experimental system of fully 
automated stations. The stations in the 
experiment settled on a 300 bps packet 
radio network linking packet bulletin 
board systems (PBBS) and, over the 
years, have moved hundreds of 
thousands of pieces of traffic across the 
continent and even internationally. 


The STA participants have 
demonstrated that HF is a viable 
medium through which data can be 
successfully moved by fully automatic 
stations. 


However, the STA by its nature, 
limited the number of stations. It did 
nothing directly to determine if sucha 
network could survive in a "free for 
all." 


A Proposal 

I would like to propose that the 
ARRL Board, through the Digital 
Committee or other expedient, scrious- 
ly consider the following proposal. 


1) Allow fully-automatic operation on 
all authorized data modes in the fol- 
lowing band segments: 


10.125-10.150 MHz 
18.093-18.118 MHz 
24.915-24.940 MHz. 


2) Require that fully automatic stations 
-have a means of assuring that their 
automated transmitters cannot 
transmit continuously for more than 
two (2) minutes per transmission. 


TAPR is a non-profit, volunteer operated Amateur Radio organization. Membership in TAPR, including a subscription to 
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3) Allow the STA to continue until six 
(6) months after the FCC adopts 
these rules to allow the existing 
mail forwarding system to migrate 
to these sub-bands without undue 
disruption to the service. 


I believe this proposal will address 
all the objections listed: 


1) There are no forcign phone 
operators on these band segments. 


2) These "W ARC" bands are allocated 
worldwide; thus there is no conflict 
in spectrum assignment. 


3) The “genie” is simply being allowed 
into a larger bottle. If the fully- 
automatic operations authorized 
prove to be unmanageable, we will 
not have seriously impeded other 
existing Amateur operations. 


4) These segments would be open to 
any Amateur stations otherwise al- 
lowed to use these frequencies to 
run fully automatically. The sys- 
tem would become self-regulating 
in that if it doesn’t work due to 
overload, stations will drop out. It 
will then either find a kind of equi- 
librium, or it will fail. 


Other Advantages To This 
Approach 

There are a number of other ad- 
vantages to this suggestion. 


1) The 30, 17 and 12 meter bands are 
sparsely occupied at the present 
time. Allowing fully-automatic 
operations on these band segments 
will help occupy this important 
spectrum resource, helping to 
prevent another 220-222 MHz 
debacle. 
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2) Because there are relatively few 
operations on these band segments, 
there can be no strenuous objec- 
tions by traditional Amateur 
operators that the automated sta- 
tions are disruptive. 


3) These bands have propagation char- 
acteristics that should allow opera- 
tion at least as effective as the 
present 40 and 20 meter operations. 


4) This proposal is a logical progres- 
sion of the STA. The band seg- 
ments are limited, so automatic 
operations are effectively con- 
tained. There is no list of 
authorized stations, so anyone may 
try automatic operations. Contend- 
ing with the increased number of 
stations may lead to additional 
protocol and modem develop- 
ments, both of which are good 
things to do. 


5) The proposed band segments 
reserve the bottom 25 kHz of each 
WARC band for weak signal and 
other data communications, 
protecting them from interference 
by automated stations. 


6) The proposed band segments are 
each only 25 kHz wide, for a total 
of 75 kHz. 


7) The proposal does not endorse or 
exclude any particular protocol or 
methodology of data communica- 
tions. It is not biased towards pack- 
et, AMTOR or any other data mode. 


8) The minimal requirement of a trans- 
mitter "watchdog" serves to protect 
the channel from a runaway trans- 
mitter in an unattended site. It does 
not unduly restrict experimenta- 


tion, nor specify any medium ac- 
cess protocol. 


9) Itrepresents a balanced compromise 
between those that would open all 
HF spectrum to fully-automatic sta- 
tions and those that would deprive 
the Amateur community of a valu- 
able resource already used, directly 
or indirectly, by thousands of 
Amateurs on a daily basis through 
the STA participants. 


Conclusion 

If you think this proposal is a good 
idea, please let your ARRL Director 
know about it. I have sent a copy of it 
to my Director, Fried Heyn, 
WA6WZO. I hope an objective and 
reasoned approach to this problem, 
with positive suggestions for com- 
promise, will lead to a satisfactory out- 
come. 


TAPR Badges! 

TAPR now offers name badges. These are 3.5 by 2.5 inches, with the TAPR 
logo and name in blue, plus your name and callsign engraved in black. It’s just 
what you’ve always needed to wear to hamfests and swapmeets. The price is $10 
(including shipping in the U.S.). 
Your badge will be engraved exactly as shown below: 


Packet Status Register 


Page 27 


The Tucson Amateur Packet Radio Corporation is a non-profit, 
scientific research and development corporation. TAPR is 
chartered in the State of Arizona for the purpose of designing and 
developing new systems for packet radio communication in the 
Amateur Radio Service, and for freely disseminating information 
required during, and obtained from, such research. 


The officers of the Tucson Amateur Packet Radio Corp. are: 


Bob Nielsen, W6SWE President 
Dave Toth, VE3GYQ Vice President 
Mike Lee, WB6RTH Secretary/Treasurer 


The Packet Status Register is the official publication of the 
Tucson Amateur Packet Radio Corporation. Explicit permission 
is granted to reproduce any material appearing herein, provided 
credit is given to both the author and TAPR. 


TAPR Membership and 
PSR Subscription Mailing Address: 
Tucson Amateur Packet Radio Corp. 
PO Box 12925 
Tucson, AZ 85732-2925 
Phone: 602-749-9479 
FAX: 602-749-5636 
Office Hours: Tuesday - Friday 
10:00am - 3:00pm M.S.T. 
17:00 - 22:00 UTC 


PSR Editorlal (Only) Address: 
, Bob-Hansen, N2GDE 
" PSR Editor 
P.O. Box 1902 
Elmira, N.Y. 14902-1902 
CompuServe: 71121,1007 


TAPR Board of Directors 

Board Member Term CompuServe 
Clark, Tom W3IWI, 1993 71260,3640 
Crawford, Jerry K7UPJ, 1994 70521,2356 
Davis, Jack WA4EJR 1994 72356,441 
Eaton, Pete WB9FLW, 1993 72727,2641 
Jones, Greg WDSIVD, 1994 72047,3455 
Morrison, Dan KV7B, 1994 70541,2374 
Nielsen, Bob W6SWE, * 1994 71540,2364 
Price, Harold NK6K, 1993 71635,1174 


Toth, Dave VE3GYQ, * 1993 = 72255,152 


Date is expiration of term on Board of Directors. 

Asterisk indicates member of Executive Committec. 

The TAPR Board of Director members “attend” a meeting, 
which is continuously in session, in a reserved area on the 
CompuServe information network. The Board encourages 
input from all interested members. If you have an issue you 
want addressed, or an idea for a project you would like TAPR 
to sponsor, contact any Board member, or drop a note to the 
TAPR office. 


To send E-mail to a CompuServe account from the Inter- 


net, use the address: 
XOCKKK . IAKX A compuserve .com 
where the X’s are the CompuServe ID number. Note: be 


sure to use a period, not a comma, in the ID number. 
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